Date: Tue, 10 Dec 1996 15:29:54 -0500 (EST) From: "Marc G. Fournier" <scrappy@hub.org> To: "Eric L. Hernes" <erich@lodgenet.com> Cc: hackers@FreeBSD.ORG Subject: Re: Multiple Buffer allocation of Shared Memory Message-ID: <Pine.NEB.3.95.961210151724.374T-100000@hub.org> In-Reply-To: <199612101935.NAA16873@jake.lodgenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Dec 1996, Eric L. Hernes wrote: > Yup, > * The Design and Implemenatation of the 4.4BSD Operating System > ~page 139 > * UNIX Internals The New Frontiers > ~page 440 > Will hit the store this afternoon...thanks... > One way, is to open a (previously agreed upon) named file that > will be used to share data, ftruncate() it to the size you want, > then mmap() it. Other processes can open and mmap() this same file > to get at the data. After the mmap(), you've got a pointer to the > data, you can cast it to whatever you like, just like with shmat(). > The biggest problem here is that all programs will have to agree > on the named file, but if you use the SysV stuff, they all have to agree > on the shmid, so it's not a showstopper. Terry has already outlined > a solution that avoids this problem. In a nutshell, open()/mmap() > are roughly analogous to shmget()/shmat(), and munmap()/unlink() > are roughly analogous to shmget()/shmctl(). One thing that named files > and mmap() can buy you is persistance of data across a reboot(), whether > that is good or bad is up to you. > Okay...this makes a bit of sense (this is new to me, its got to click into place first to make perfect sense *sigh*)... So, if I where to be getting a frame of data from a remote end using sockets, I'd want to do something like: get size of frame open named file ftruncate() named file to size of frame mmap named file write frame to mmap'd region Does that make sense? Now, "child" processes accessing that MMAP'd area...Terry (I believe?) mentioned passing the file descriptor through a socket from the parent to the child, which, to me, sounds okay if you have few children reading the mmap()'d region...but what I'm working on is going to require 1000's of child processes reading that mmap()'d region, and having 1 socket open for each child doesn't sound very efficient. You mention a named file in your example, so each frame could be called '001', '002'...'999', with the child processes accessing them sequentially, as they exist...but at that point, I may as well just write the date to 001, and have the child process open, read, close... I think what I'm still missing is that the way mmap() is being described is that it requires a file to work off of, and all that the benefit is is that each child can share the data from the same memory region...what I'm *trying* to accomplish is a completely "in memory" solution, without using something like MFS to get off of the physical device. I know that I'm currently missing something that is totally obvious to those that have a better understanding of mmap/shm...thanks for the patience... Marc G. Fournier scrappy@hub.org Systems Administrator @ hub.org scrappy@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.95.961210151724.374T-100000>