Catch 22

[David Reid <dr...@jetnet.co.uk>]

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!

As the memory stuff is still in it's infancy I think we'll have to just
stick the issue on the back burner for now and hopefully come back to it.
I'll add some stuff to the TODO file with the stuff from the discussions as
well...

david

Re: Catch 22

[David Reid <dr...@jetnet.co.uk>]

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" <lk...@samba-tng.org>
To: "David Reid" <dr...@jetnet.co.uk>
Cc: <de...@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
>

Re: Catch 22

[Luke Kenneth Casson Leighton <lk...@samba-tng.org>]

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

Re: Catch 22

[Greg Stein <gs...@lyra.org>]

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!

Dynloading memory management seems a bit misguided. Just how much
flexibility does an app truly need? Relinking is easy enough. Or maybe
compile one file and relink. That definitely beats some of the old
techniques of recompile-the-world.

But dynload? That seems excessive.

> As the memory stuff is still in it's infancy I think we'll have to just
> stick the issue on the back burner for now and hopefully come back to it.
> I'll add some stuff to the TODO file with the stuff from the discussions as
> well...

Please move that TODO into the STATUS file. We can't track stuff if it is
all over the repository. The STATUS file does /not/ contain "stuff for
release" but also contains ideas and todos.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/