> >> > 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.
>
> 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 would be a good step in the right direction.
> > [...]
> > I have also noticed that 9 times out of 10, if the APR configure script
> > fails, it fails while trying to configure MM.
>
> When did MM's configure script fail and with what error/problem?
> The only error I've heard of is that on some Solaris 2.8 boxes the
> determination of the maximum shared memory segment size failed for
> unknown reasons. Unfortunately I was unable to reproduce this on any of
> my own Solaris 2.8 boxes.
I have seen this break in the same place on AIX, HP/UX, and Linux (when my
/tmp partition was full).
> > 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.
>
> Oh yes, MM's Autoconf is stuff is undoubtedly horrible complex. I
> would like to see it less complex myself, believe me. Feel free to
> re-implement it, but don't be surprised if you fail to make it actually
> less complex. The complexity is definitely inherited from the problem
> domain here.
I don't really have any desire to hack on MM. I did a very thorough
review of MM when I initially wrote the APR shared memory stuff, and I
reviewed it again when I hacked in the solution to MM using parts of the
memory that I had asked for. In general, I found that I just couldn't
easily follow the code. I have no desire to dig around in the code again.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
