httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: APR shared memory requirements.
Date Sat, 05 May 2001 16:24:29 GMT

> > 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?

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.

> > 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.

I disagree that this is not portable.  I have never seen a platform that
supports shared memory that does not support key-based shared memory.
Anonymous shared memory is just keyed memory that can be ignored once it
is set up.

> 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.

As I said, I disagree that this is what we want.  Even if it does work, I
disagree that it is a good idea.  MM is already 3 levels deep, and the MM
APR is the top-most level.  Layering APR's shared memory on top of the MM
API is the wrong solution IMO.  It just makes this code more complex than
it needs to be.

I have also noticed that 9 times out of 10, if the APR configure script
fails, it fails while trying to configure MM.  I believe that MM's
configure script is too complex, and a lot of what MM implements is either
already in APR, or it isn't needed by APR.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message