From owner-freebsd-hackers Tue Dec 10 12:21:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA26783 for hackers-outgoing; Tue, 10 Dec 1996 12:21:20 -0800 (PST) Received: from bacall.lodgenet.com (bacall.lodgenet.com [205.138.147.242]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA26771 for ; Tue, 10 Dec 1996 12:21:08 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id OAA00154; Tue, 10 Dec 1996 14:20:21 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma000144; Tue Dec 10 14:20:05 1996 Received: from jake.lodgenet.com (jake.lodgenet.com [10.0.11.30]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id OAA30897; Tue, 10 Dec 1996 14:20:18 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.8.3/8.6.12) with ESMTP id OAA17243; Tue, 10 Dec 1996 14:20:37 -0600 (CST) Message-Id: <199612102020.OAA17243@jake.lodgenet.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Sean Kelly cc: "Eric L. Hernes" , "Marc G. Fournier" , hackers@FreeBSD.ORG Subject: Re: Multiple Buffer allocation of Shared Memory In-reply-to: Your message of "Tue, 10 Dec 1996 13:01:45 MST." <32ADC1A9.3832@fsl.noaa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Dec 1996 14:20:37 -0600 From: "Eric L. Hernes" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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