In article <[EMAIL PROTECTED]> you wrote:
> Most people have realized that APR's shared memory support isn't good
> enough to support Apache, or in reality most other applications. We had
> this discussion during the hack-a-thon, and we came up with a small list
> of requirements for APR's new shared memory implementation. Here are the
> notes:
>
> 1) malloc-like implementation
APR currently is based on MM and MM already provides a malloc-style
high-level API. So this is trivial from my point of view. Do I miss
something here?
> 2) Anonymous and Key based shared memory support
With "key-based" I guess you mean that one can attach to an existing
shared memory segment with a key, right? Unfortunately this is not
really portable across all platforms. too. Same for "anonymous segments"
where I guess you mean the BSD-style MMAP_ANON stuff, i.e., where the
shared memory segment is not tried to any file or /dev/zero, etc.
That's why MM through its API only supports shared memory segments
(without saying whether they are actually anonymous or tied to a file,
etc.) which cannot be attached by unrelated processes (i.e., not
sub-processes forked off from the same parent which created the shared
memory segment). This was the only way you really can achieve high
portability across a wide range of Unix platform.
> [...]
> As the first note in this list says, it should look a lot like
> malloc() if at all possible.
As I said, under Unix you just have to 1:1 map your APR malloc PI onto
AMM's malloc-style API. Under other platforms I don't know whether a
malloc-style API for shared memory segments exists or whether one has to
code it oneself.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
