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 Sat, 09 Jun 2001 01:01:14 GMT
> > > Argh!  I also thought that the purpose of SMS was to replace
> > > and not pools.  If you want to replace pools, then the code should not
> > > be called apr_sms_blah.  Pool is the name for our memory system --
> > > does not, and never has, defined the type of memory behind it.
> >
> > pool is the name of the _current_ memory system. There will be a
> > sms called pool aswell. You get a pool like system by doing
> > apr_sms_pool_create() [this is still a todo, but I'm working on it].
> I don't think you are following my drift.  There exists a memory system
> within APR.  It is called a pool.  If anyone here attempts to replace the
> HIDDEN INTERNALS of that memory system with some new sms thingy and then
> suggests that we should change all calls to apr_pool with apr_sms_pool,
> I am going to throttle them with a baseball bat (and then -1 the patch).

Ouch. :)

> We have an abstraction.  We will have the same abstraction with sms.
> Therefore, either sms is under pool or it is a replacement for the hidden
> internals of pool with some extensions that are new.  It seems to make
> sense as a replacement, which means we code it as such and not as some
> "other" memory system.  That means we use the same names and selectively
> compile one of the two choices into apr until we are sure that the old one
> can be replaced with the new one.
> Under no circumstances whatsoever will we change all of our code to call
> sms things just because they were implemented as a superset of the current
> pool internals.  That defeats the whole purpose of abstract data types.

OK.  This seems like a good idea.

> > Second, with a different namespace we _can_ retain the current pools
> > api (at least long enough) next to the sms api. In the httpd, apr
> > and apr-util codebase the sms api would be preferred.
> Cruft shall not be carried forward unless it is necessary for backwards
> compatibility.
> > > Just use the same names as apr_pool.c and selectively compile one or
> > > the other.
> >
> > The fun is that you don't have to compile one in, you could decide at
> > runtime if you please.

So, possible roadmap for moving forward...

- keep working on the sms code as apr_sms for the time being.  We keep doing
this until we have an sms module that could replace the current pool code.
- build into configure a switch for new/old pool code, keeping the default
as the current code
- move the pools.c file into the memory/unix directory and add logic to
Makefile.in to build pools.c or the sms stuff
    o at the same time change the top level API's for the sms code to look
like apr_pool_t semantics
    o remove the lib directory
- contiue development and add to the API such that we have the full range of
flexability of the sms concept but called apr_pool_t
- when we're ready change the default option in APR to the new code

Carrying on what's been started in the sms code under a seperate namespace
should mean we don't cause too much grief until we're ready to make the
I'm only suggesting moving the pools.c file as that way all memory files are
in a single location which seems to make more sense.  IN fact it might make
more sense to have the top level apr_sms.c file in the memory directory and
the seperate sms modules in the platform specific directories.  We can
debate this but I don't care one way or the other.

> There is nothing fun about bloated runtimes.


If people are happy with this then this is how we'll proceed and in a while
when we're ready to move to stage 2 we'll no doubt have another discussion
about the exact details of how we do things :)  We do like talking don't
we??  Of course some of us prefer words to baseball bats Roy :))


View raw message