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?
>
> 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.
> [...]
> 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 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.
Yours,
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
