From: "Justin Erenkrantz" <[EMAIL PROTECTED]> Sent: Wednesday, July 18, 2001 11:52 AM
> [ Not sure if you meant to send this on-list or not. ] I meant to... so here it is... > On Wed, Jul 18, 2001 at 11:25:54AM -0500, William A. Rowe, Jr. wrote: > > I think you have something here ... even an allocation pool > > (thread-specific). > > I believe that thread-allocation sms will still need to be the 'scope' child > > of the root pool, even if it does allocation all on it's own. > > Given the current code for SMS, it is hard to separate the 'scope' vs. > 'allocation' parent. Roy and I discussed yesterday about playing some > trickery with having the thread-specific SMS be parented by the std SMS > (i.e. malloc et al) and the per-process pool (i.e. passed into > thread_create) have the thread-specific SMS listed as a child. The > problem now becomes what happens when that thread-specific SMS is > cleaned up (voluntarily - like it will be 99% of the time)? You now > need to remove it from the per-process SMS's child list. This now > becomes an expensive operation. (The SMSs only store their next > sibling, not their previous sibling, so they can't easily remove > themselves from the list.) Now that's a specific flaw (one that can be solved.) > We thought that the cleanup strategy makes a bit more sense (if not > clever). *If* you can handle the case of the thread being destroyed > and it unregisters the cleanup that the parent SMS has *or* the > apr_sms_reset function won't SEGV if the SMS has already been reset > or destroyed. Which I think we can do either. -- justin Ugh... I'm certain I don't want _users_ managing this cleanup registration. I believe it's safer to have a semantic that offers, "hey, give me a sub pool of foo, using the bar allocator", and keeping the eye on it ourselves. It's really no different than cleaning up a child today, walk up to the parent and call pool_destroy.
