Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 7 May 2001 13:24:46 +0200
From: "Ralf S. Engelschall" <rse@engelschall.com>
To: new-httpd@apache.org
Subject: Re: APR shared memory requirements.
Message-ID: <20010507132446.A48572@engelschall.com>
Reply-To: rse@engelschall.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Organization: Engelschall, Germany.


In article <Pine.LNX.4.33.0105061214400.20277-100000@twinlark.arctic.org> you wrote:

>> No, Dean, I think you misunderstood me here. If the shared memory
>> segment is full, I don't want to _replace_ it with a larger one. I
>> just want to _add_ another _new_ shared memory segment to the memory
>> pool and allocate the requested chunk of memory from there instead. The
>> same way a heap-based allocator uses sbrk(2) again and again to get more
>> heap segments I want to allocate more and more shared memory segments.
> 
> oh i know you don't want to grow the existing segment -- but in order to
> add new segments you need to co-ordinate with all processes.  you can't
> accomplish this the same way that anon-mmap() and fork() do -- you need to
> have a handle which all processes can use to open the memory.  that's
> going to be a filename on unixes that don't have sysv shm...
> 
> also, the rest of the problem is that all references to the shared memory
> need to be indirected -- because you can't be sure if the process you're
> running in has the segment you need mapped.

Ohhh... now I understand the point. Puuhh.. yes, correct. I've totally
overlooked these issues. Hmmm... but then: do have any chance to provide
such functionality in a portable way at all?

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com