apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: cvs commit: apr/threadproc/unix thread.c
Date Wed, 06 Jun 2001 21:25:47 GMT
On Wed, 6 Jun 2001, David Reid wrote:

> There is no pleasing some people is there??

Nope.  =-)

> 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.
> apr_pstrdup(apr_pool_t *pool, char *str)
> we'll end up with
> apr_pstrdup(apr_sms_t *mem_sys, char *str)

See, that's where my overall view of "where we hope to get to" differs.
<shrug>  In my mind, APR depends on pools.  Period.  It would require a
major overhaul for most APR operations to be safe WITHOUT pools (ie, lots
of apr_sms_free operations would have to be added, which is exactly what
the pools are meant to avoid).  So in my mind, you implement pools ON TOP
OF sms.  That gives you the best of both worlds: you get the convenience
of the pool API, and you get to select where the pool gets its memory from
under the covers (does it come off the heap, or out of shared memory, or
what?  The sms that the pool's based on decides.)  So you can't do

newstr = apr_pstrdup(apr_sms_t *mem_sys, char *str)

because then you have to be sure to


because you don't know for sure whether the mem_sys will do it for you or
not.  So that means you have to keep

newstr = apr_pstrdup(apr_pool_t *pool, char *str)

and change the apr_pool_t struct to include an sms, and to get its memory
using apr_sms_malloc instead of just plain old malloc.

That's my take on things, anyway.

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

I don't really have a problem with the locking end of things, per se...
there will probably be some SMS's that need to lock, so we might as well
give them a convenient means to do so.  I think.  I haven't really looked
into this, though.

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

I'm not going to say -1... just -0.  <shrug>


   Cliff Woolley
   Charlottesville, VA

View raw message