httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: APR shared memory requirements.
Date Sun, 06 May 2001 08:22:28 GMT

In article <> you wrote:

>> > MM does not have a malloc-like API.  It comes close, but the first thing
>> > MM makes you do to get shared memory, is to decide how much shared memory
>> > you want total.  That would be fine, but then if I request 1024k of shared
>> > memory, and only allocate it in smaller blocks, then MM will use portions
>> > of my 1024k for itself.  That means that I can't allocate all 1024k for
>> > myself.
>> And what do you suggest for improvement, Ryan?
>> The only really reasonable possibility from my point of view (and
>> which is in my TODO list for a longer time) is that MM's "Standard
>> Malloc-Style API" bases its memory pool not on just a single shared
>> memory segment, but on multiple segments and then automatically adds a
>> segment if the pool is exhausted. A patch for this is welcome.
> this doesn't even sound possible at all.  you can't force a shared memory
> mapping to appear at the same address in another process, and you can't
> even force another process to attach a new shared mem segment.
> this would mean you couldn't use pointers in the shared memory.  ok maybe
> this is already a restriction and you guys use offsets from the shm base.
> but with a dynamically expandable change like this then you're going to
> require every offset/pointer dereference is going to require a test first
> to see if that part of the shared memory is already mapped.
> not to mention that unless you've got sysv shm, then you need to create
> files on disk somewhere to be backing store for the memory, because
> there's no other way to pass a segment to another, already existing
> process.

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.

> 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?
> it sounds to me like what the "must look like malloc" folks want is more
> commonly referred to as multithreaded programming.

<grin> Yes, maybe...
                                       Ralf S. Engelschall

View raw message