From owner-freebsd-hackers  Tue Dec 10 13:24:01 1996
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id NAA02105
          for hackers-outgoing; Tue, 10 Dec 1996 13:24:01 -0800 (PST)
Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA02070
          for <hackers@freebsd.org>; Tue, 10 Dec 1996 13:23:56 -0800 (PST)
Received: from sol1.gud.siemens.co.at (root@[10.1.143.100]) by zwei.siemens.at (8.7.5/8.7.3) with SMTP id WAA25618 for <hackers@freebsd.org>; Tue, 10 Dec 1996 22:23:27 +0100 (MET)
Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp
	(Smail3.1.28.1 #7 for <hackers@freebsd.org>) 
	id m0vXZe2-0001zWC; Tue, 10 Dec 96 22:23 MET
Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37)
	id AA197322970; Tue, 10 Dec 1996 22:22:50 +0100
From: "Hr.Ladavac" <lada@ws2301.gud.siemens.co.at>
Message-Id: <199612102122.AA197322970@ws2301.gud.siemens.co.at>
Subject: Re: Multiple Buffer allocation of Shared Memory
To: erich@lodgenet.com (Eric L. Hernes)
Date: Tue, 10 Dec 1996 22:22:50 +0100 (MEZ)
Cc: kelly@fsl.noaa.gov, erich@lodgenet.com, scrappy@hub.org,
        hackers@freebsd.org
In-Reply-To: <199612102020.OAA17243@jake.lodgenet.com> from "Eric L. Hernes" at Dec 10, 96 02:20:37 pm
X-Mailer: ELM [version 2.4 PL24 ME8a]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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