Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 27980 invoked by uid 500); 19 Sep 2001 19:31:54 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 27969 invoked from network); 19 Sep 2001 19:31:54 -0000 Errors-To: Message-ID: <037d01c14141$d1416c90$93c0b0d0@roweclan.net> From: "William A. Rowe, Jr." To: "Jon Travis" , References: <20010917155221.A15053@covalent.net> <20010919112605.P4050@lyra.org> <02dc01c1413a$d2b0b830$93c0b0d0@roweclan.net> <20010919191624.A7EF846DFC@koj.rkbloom.net> <20010919122735.A14657@covalent.net> Subject: Re: New post-log-transaction hook? Date: Wed, 19 Sep 2001 14:32:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N From: "Jon Travis" Sent: Wednesday, September 19, 2001 2:27 PM > On Wed, Sep 19, 2001 at 12:16:24PM -0700, Ryan Bloom wrote: > > On Wednesday 19 September 2001 11:37 am, William A. Rowe, Jr. wrote: > > > > > > Considering how we use pools for dynamic libraries and the rest, it's > > > absolutely vital that they are unspun from the pool in LIFO order of their > > > creation. > > > > I agree with Bill. Having reviewed the code quite deeply yesterday, pool > > cleanups follow a very clean rule, and registering a cleanup from within > > a cleanup will always work if done correctly. If you have data in a pool > > BZzzzt. The attached code registers a cleanup from within a cleanup, and > does so 'correctly'. See the program attached at the bottom, which behaves > incorrectly. It is simple code, but not knowing that a given > function registers a cleanup can cause major problems (leaking > file descriptors, etc. eventually). The file should contain 'Cleanup', > because the cleanup of the file should flush the buffer -- that > cleanup is never run, though. Jon, there is no _doubt_ that it's broken right now. I was speaking of the 'ideal', not today's borked behavior. Extending the LIFO cleanups idea as a stack, we should be popping as we call each cleanup, and allowing new cleanups to be pushed onto the end of the cleanup stack..