Date: Tue, 10 Dec 1996 22:22:50 +0100 (MEZ) From: "Hr.Ladavac" <lada@ws2301.gud.siemens.co.at> To: erich@lodgenet.com (Eric L. Hernes) Cc: kelly@fsl.noaa.gov, erich@lodgenet.com, scrappy@hub.org, hackers@freebsd.org Subject: Re: Multiple Buffer allocation of Shared Memory Message-ID: <199612102122.AA197322970@ws2301.gud.siemens.co.at> In-Reply-To: <199612102020.OAA17243@jake.lodgenet.com> from "Eric L. Hernes" at Dec 10, 96 02:20:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
E-mail message from Eric L. Hernes contained: > Sean Kelly writes: > >Eric L. Hernes wrote: > > > >> 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. > > > >But bear in mind where the file is located. If it's on a UFS, then your > >system will have to do physical I/O to update the file on disk as > >processes mmap'ing it make updates. That's why it's often better to > >locate mmap'd files used for IPC on an MFS filesystem. > > > > correct me if I'm wrong here, but doesn't MFS allocate backing store > in swap, so it could be paged out via physical I/O too. In either case > the physical IO appears async -- the physio won't happen until > the system needs ram, or the pages are inactive. If you've got enough > ram, the mmap'ed file won't be flushed out no matter what the underlying > FS is. Or do I just have too much faith in the VM system? ;-) This should be irrelevant, as mmapped files should not get written to until msync, or perhaps pageout (I don't know what POSIX draft says about it). AFAIK, they need to be updated on close, though. I don't know what should be the right thing for files mapped as MAP_PRIVATE. /Marino
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612102122.AA197322970>