Date: Tue, 10 Dec 1996 14:20:37 -0600 From: "Eric L. Hernes" <erich@lodgenet.com> To: Sean Kelly <kelly@fsl.noaa.gov> Cc: "Eric L. Hernes" <erich@lodgenet.com>, "Marc G. Fournier" <scrappy@hub.org>, hackers@FreeBSD.ORG Subject: Re: Multiple Buffer allocation of Shared Memory Message-ID: <199612102020.OAA17243@jake.lodgenet.com> In-Reply-To: Your message of "Tue, 10 Dec 1996 13:01:45 MST." <32ADC1A9.3832@fsl.noaa.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
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? ;-) > >-- >Sean Kelly >NOAA Forecast Systems Laboratory kelly@fsl.noaa.gov >Boulder Colorado USA http://www-sdd.fsl.noaa.gov/~kelly/ eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612102020.OAA17243>