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. Hmm... > > 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 -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
