httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: APR shared memory requirements.
Date Sun, 06 May 2001 19:18:26 GMT
On Sun, 6 May 2001, Ralf S. Engelschall 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.

> > i really think that MM's rather simple API is the right API.  and that
> > what's being suggested is overkill, and will hurt performance.
>
> What type of API do you suggest instead, Dean?

well the problem you guys seem to be looking at is a table lookup problem,
which is why i suggested sleepycat ... db2/3 can be mapped read/write from
multiple processes (and it uses mmap() to map in pages of the database as
required, plus a bunch of other nice features).  of course the license
won't make most of you happy ;)

-dean


Mime
View raw message