Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-ID: <02db01c10fab$947d52f0$93c0b0d0@roweclan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: <dev@apr.apache.org>
Subject: Fw: [PATCH] Allow unrelated SMSes to reset
Date: Wed, 18 Jul 2001 12:02:31 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

From: "Justin Erenkrantz" <jerenkrantz@ebuilt.com>
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.