apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@samba-tng.org>
Subject RE: cvs commit: apr/threadproc/unix thread.c
Date Fri, 08 Jun 2001 22:44:19 GMT
> On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote:
> > We could implement pool using sms but we'd loose a great deal
> > of flexibility
> > and a great opportunity to make APR even more useful.
> >
> > Pools are a single way of dealing with handing out memory.  they imply a
> > degree of overhead and while they work eveyrwhere there is some
> > degree of agreement that they're overkill in a lot of cases.  So why do
> 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].

> The current pool code is completely screwed for threaded environments
> because of the mutex locks.  httpd 2.0 will not be production ready on
> threaded servers until we can get rid of that locking within worker pools.
> If the solution to that is to replace pools with sms, then let's get
> to it, but we should do so without creating a new sms namespace.

Well, it is very hard to avoid that, because the sms api is more
'advanced' as the pools api. What can be done is retaining the pools
api in terms of sms. For example like this:

#define apr_pool_t                   apr_sms_t
#define apr_pool_create(sms, parent) apr_sms_pool_create(sms, parent)
#define apr_palloc(sms, size)        apr_sms_malloc(sms, size)
#define apr_pcalloc(sms, size)       apr_sms_calloc(sms, size)
#define apr_prealloc(sms, mem, size) apr_sms_realloc(sms, mem, size)
#define apr_pool_clear(sms)          apr_sms_reset(sms)
#define apr_pool_destroy(sms)        apr_sms_destroy(sms)

In the same way cleanups can be done, but they don't match one on
one [the sms cleanup system is meant to be more generic. There are
still some tricks that need to be implemented, but we'll get to that]

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.

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

> .....Roy


PS. How things were envisioned changed along the way, but IMHO that isn'y
    necessarily a bad thing...

View raw message