Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 57185 invoked by uid 500); 7 Sep 2001 12:26:33 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 57167 invoked from network); 7 Sep 2001 12:26:32 -0000 Date: Fri, 7 Sep 2001 14:25:58 +0200 From: Luke Kenneth Casson Leighton To: dcerpc-dev@lists.dcerpc.org Cc: dcerpc-dev@dcerpc.org, dev@apr.apache.org, samba-technical@samba.org Subject: Re: Shared memory and IPC Message-ID: <20010907142558.D7226@angua.rince.de> Mail-Followup-To: dcerpc-dev@lists.dcerpc.org, dcerpc-dev@dcerpc.org, dev@apr.apache.org, samba-technical@samba.org References: <20010907123043.F5674@angua.rince.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from wez@thebrainroom.com on Fri, Sep 07, 2001 at 11:50:40AM +0100 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, Sep 07, 2001 at 11:50:40AM +0100, Wez Furlong wrote: > On 07/09/01, "Luke Kenneth Casson Leighton" wrote: > > > The real question is, what *do* you do on failure? One possible > > > protocol: the "master" process does mmap() without MAP_FIXED, reports > > > the address to the others via some sort of existing IPC, the rest try > > > with MAP_FIXED, report back success or failure. If anyone fails, they > > > all unmap *except* the master, which repeats the process with another > > > mmap() [again without FIXED] ... for a specified number of tries. Upon > > > success, or upon giving up, the master munmaps all failed segments, if > > > any. > > Yes, but... (see below) > > > see, this is the bit that i was hoping that noone would suggest > > even be attempted, even though it's technically a correct > > solution :) > > Sounds like a lot of effort on the part of all processes involved. > What if a new process is introduced after the others have negotiated > the address space that cannot map those address(es)?? you know, this _does_ tend to suggest that the protocol implemented by transport enumeration behind the epmapper would be useful. an additional system call which gives an array of memory ranges that will succeed, or is likely to succeed, if mmap is called immediately with MMAP_FIXED. ... or is that overkill? luke