Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-ID: <109a01c142ac$1f2a7990$93c0b0d0@roweclan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: <dev@httpd.apache.org>
References: 
 <20010917155221.A15053@covalent.net><20010919112605.P4050@lyra.org><02dc01c1413a$d2b0b830$93c0b0d0@roweclan.net><20010919191624.A7EF846DFC@koj.rkbloom.net><20010919122735.A14657@covalent.net><20010920111855.C20983@clove.org><20010920174845.P4050@lyra.org>
 <15275.19146.416375.743958@tin.cozy.org>
Subject: Fix broken cleanups model
Date: Fri, 21 Sep 2001 09:42:27 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Ben Hyde" <bhyde@pobox.com>
To: <dev@httpd.apache.org>
Sent: Friday, September 21, 2001 9:12 AM
Subject: Re: [PATCH] fix cleanups in cleanups


> I also think it's a long standing mistake that the subpools aren't
> unwound via the same cleanup stack as everything else but have their
> one one off to the side; that's a royal pain when you want to allocate
> a node into it's own subpool while doing things like the above.

Agreed.  Here are my thoughts.

We introduce an apr_cleanup_t.  This is a _single_ cleanup holder for
mutiple, extendable types of cleanups (at this moment, pool cleanup and 
cleanup for exec.)  

All apr types (and http types) that need cleanups get one of these 
records.  Because it exists _within_ the allocated data, we can 
set/unset them at will.  This would no longer change the registrated
ordering.

The API must _allow_ us to move the ordering when it's absolutely
appropriate.  If a type is created, but a second call does the 'dirty
work' of obtaining the resource (such as make/create or create/open 
pairs) then the order must be fixed to obtaining the resource.  If
someone used the apr structure before a resource is obtained, they
really have a placeholder, not the live resource.

We allow users to register a cleanup as we always have.  Once it's
registered, they have an apr_cleanup_t.  They can unset that cleanup
and register another (changing the order), or they can simply change
their given cleanup.  Whichever is appropriate for that call.

As with any library code, a cleanup must be tolerant that _anyone_
could have closed an apr type, either in the mainline, by reacting to
some event, or in it's own reordered cleanup.

Finally, an apr_pool_t is just another apr type.  Its cleanup gets
invoked by the mainline cleanup code.  I still need to ponder just
what the interaction between two pool's cleanups are, but I'll save
that for another mail after this headcold clears a bit.  Hope this
part made sense.

Bill