apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: cvs commit: apr/threadproc/unix thread.c
Date Wed, 06 Jun 2001 20:59:46 GMT
There is no pleasing some people is there??

Here I go with an explanation of why I made the change...

At present pools are a specific implementation of memory management.  In
time we hope to get sms to a point where we can replace pools with an sms
module that is better.  When we get there, it won't matter that we have
pools in the sms code as when we replace the pools we'll have to go through
and change all the apr code.

So at present have

locks -> apr_pool_t
sms -> locks -> apr_pool_t

When we're done we'll have

locks -> apr_sms_t
sms -> locks -> apr_sms_t

So personally I don't see the problem and thus I made the change!  I guess
maybe it's because people keep saying that we're going to change the pools
to use sms.  Why?  To get the maximum flexibility we'll need to use sms
throughout so while we may have

apr_pstrdup(apr_pool_t *pool, char *str)

we'll end up with

apr_pstrdup(apr_sms_t *mem_sys, char *str)

That's what I'm aiming at and that's why I keep saying that we won't get to
this point until we've released apache.  I mean if we had a really kick ass
sms module today that we'd tested to destruction then it'd almost be worth
making the change, but we're not there yet and won't be for a while.  When
we do make the change we'll just make an apr_pool_t == apr_sms_t so we ease
the job we'll make for our client apps.

Now that's all in the future and is where I think we'll end up, but until
then we need to be able to use apr from within the memory code.  the
addition of a pool isn't a big deal really - view it as another type of
sms - after all it is a memory system isn't it?

We've done it before when we went from context => pool so it's not a huge
problem but we need to wait until a release.

As for locking, well the logical level for locking to be implemented is in
the sms module.  Look at the standard module. malloc should be thread safe
so no locking should be required, hence we don't have any.  In a tracking
system we can't guarantee that so we lock.  In a system that dumps the
memory we'd want to lock around the routine that writes to the file as we
wrote correctly.  However, it's really a choice that should be made at sms
level.  Does that make more sense? I'm not sure how many modules we'll end
up with and there's nothing to stop platform specific modules being written.

It's even possible we'll have specialist modules for certain specialist
purposes.  That's one of the reasons why I still think it'd be interesting
to have dynamic loading of modules so that people can ship binary apache
modules and their own specialist memory modules as well.  Just a wild notion
:)

So, do I still hear -1's for the pool in sms approach?

david

> > On Wed, Jun 06, 2001 at 06:12:17PM -0000, dreid@apache.org wrote:
> > >   - add an apr_pool_t to the sms structure
> >
> > -1 (non-veto, but awfully close).  Uh, why are we doing this?
> > I thought that a pool would be defined in terms of a sms (not now, but
> > at some point).  This would not allow that to happen.
> > I'm still not entirely sold on the fact that sms needs locks.  I think
> > the locks can be handled at a higher level than sms (i.e. a pool).
>
> I was thinking the exact same thing, actually...
>
> --Cliff



Mime
View raw message