apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: cvs commit: apr/threadproc/unix thread.c
Date Fri, 08 Jun 2001 23:18:18 GMT
> > Argh!  I also thought that the purpose of SMS was to replace malloc/free
> > 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 -- pool
> > 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).

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 more
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.

> 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.

There is nothing fun about bloated runtimes.

....Roy


Mime
View raw message