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 22:17:24 GMT
On Thu, 7 Jun 2001, Sander Striker wrote:

> Argh!!! [getting abit frustrated now, because there seems to be no
> way of moving forward and thus proving the system]

I think we're at least starting to face the issues head-on.  We're making
progress, believe it or not.  =-)

> > 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).
> This is simply not true. Where you pass in pools at the moment you'll pass
> in a _tracking_ sms later. This guarantees that stuff is free'd later on.


> > 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.)
> What you are basically saying is that you want tracking to be
> mandatory instead of optional. Why another level of indirection? sms
> is flexible enough to do what pools can do [apart from an abort
> function it has almost all the same features. Oh and locking
> ofcourse...]

Okay, so you've convinced me that it's possible to do.  But it's not going
to happen throughout APR in time for Apache 2.0, I think (I doubt anyone
here would disagree).  So what are the intermediate measures?  I'll step
back now and let you all sort that out.

> For people considering -1, please reconsider and cut us some slack so
> we can at least try and prove our case. If we don't prove anything issue
> a -1 later and we'll cut the code out [does this sound fair David?]

Okay by me.


   Cliff Woolley
   Charlottesville, VA

View raw message