Date: Fri, 13 Dec 1996 12:29:38 -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.961213122631.22277D-100000@hub.org> In-Reply-To: <199612131404.IAA08338@jake.lodgenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 13 Dec 1996, Eric L. Hernes wrote: > Are these true parent/children, or server/client. It doesn't change > *everything*, mostly it just throws out some of the shortcuts, like > inheriting file descriptors and/or mmap'd regions. > true client/server...basically, the "server" is a stand alone process that talks, via sockets, to another machine, and needs to store the information in memory, vs disk for the client(s) to access... > I think there's a correspondence between the file mode and the PROT_*, > specifically, if you open a file O_RDONLY, then mmap with PROT_WRITE, > the mmap will fail with EACCES. > Okay, makes sense...will keep that one in mind... > Yes, that looks ok. To update the image on disk, you'll need to > use msync(). I'm not sure if there's ever a predictable implicit > msync(). Certainly when memory is scarce, but that's not predicable. > Possibly when munmap'ing, or at process exit. > S'alright, the only reason I'm using a named file in the first place is for easy of connecting clients to the MMAPd region...the data will never need to be written to disk, as its out of date seconds after its created. Now, I think I have enough to actually write the shared memory aspect of things...at least now it makes a helluva lot more sense then it did :) Thanks to all... 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.961213122631.22277D-100000>