Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <024801c0e8fd$cc25e7a0$6400a8c0@godzilla>
From: "David Reid" <dreid@jetnet.co.uk>
To: "Luke Kenneth Casson Leighton" <lkcl@samba-tng.org>
Cc: <dev@apr.apache.org>
References: <023b01c0e8f3$e1c365b0$6400a8c0@godzilla>
 <20010530132019.A28736@angua.rince.de>
Subject: Re: Catch 22
Date: Wed, 30 May 2001 12:42:43 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Pools won't be using sms anytime soon.  not sure how many more times this
has to be said, but from discussions I've and the general feeling is that we
won't be changing pools over to sms until after an apache 2.0 release.  That
doesn't look like happening for a few months, so there's your timeline.
Why?  Pools have a long track record and suddenly changing the underlying
memory allocation/management for apache will make a lot of people nervous.
SMS is still in it's infancy and in time it'll be incredibly useful, but it
needs time to mature and grow.

I don't think it's a huge problem as the following seems a likely sequence
of events...

start_app
    get a standard memory system
    ask for a dynamic module to be loaded
    get a new memory system based on the dynamic module
    ...
    destroy the dyanmic memory system
    unload the dynamic module
    destroy the standard memory system
end_app

This means we should have a "memory entity" to pass when we try to load the
dynamic module.

The dso code is pretty straightforward and could be altered to use sms
instead of pools quite easily.  I hesitate to suggest having parallel
functions using sms for a while as this would just be the thin edge of the
wedge.  the locking code is also potentially required by the memory code, so
they'd have to be done and we'd get a real mess...

I think our priority should be to get shared memory support in place at the
moment :)

david

----- Original Message -----
From: "Luke Kenneth Casson Leighton" <lkcl@samba-tng.org>
To: "David Reid" <dreid@jetnet.co.uk>
Cc: <dev@apr.apache.org>
Sent: Wednesday, May 30, 2001 12:20 PM
Subject: Re: Catch 22


> On Wed, May 30, 2001 at 11:32:46AM +0100, David Reid wrote:
>
> > I've been pondering the dynamic loading stuff for memory and had a few
> > discussions off list about it, but one thing keeps hitting me.
> >
> > We really want to use the APR dynamic loading as it covers all the
platforms
> > we need quite nicely, but that uses pools, which so far we haven't had
any
> > involvement with in the memory code, which is IMHO the right thing to
do!
>
> so.
>
> the required coding order [independence] is:
>
> dynamic loading
> sms
> pools
>
> the current _implementation_ order is:
>
> dynamic loading -> pools
> pools -> direct memory access
> sms -> direct memory access
>
> the future implementation order should be:
>
> dynamic loading -> ??? a static, non-dynamic pool-based memory-thing?
> pools -> sms
> sms -> direct memory access
>
> there is nothing to stop you having the 'default' sms structure
> from always being there, such that code that performs
> initialisation, pre-dynamic-loading blah blah all still works
> and you don't have to change any existing code.
>
> what you think?
>
> luke
>