Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 12378 invoked by uid 6000); 13 Sep 1999 20:00:58 -0000 Received: (qmail 12188 invoked from network); 13 Sep 1999 20:00:50 -0000 Received: from eastwood.aldigital.algroup.co.uk (194.128.162.193) by taz.hyperreal.org with SMTP; 13 Sep 1999 20:00:50 -0000 Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id UAA00330 for ; Mon, 13 Sep 1999 20:00:04 GMT Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id VAA21929 for ; Mon, 13 Sep 1999 21:00:27 +0100 Message-ID: <37DD57C3.FB75BB36@algroup.co.uk> Date: Mon, 13 Sep 1999 21:00:03 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.6 [en-gb] (WinNT; I) MIME-Version: 1.0 To: new-httpd@apache.org Subject: Re: APR cleanup status? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org Ryan Bloom wrote: > > > > That depends on the function. If I am closing a file descriptor, I can at > > > the very least get EBADF. I think that is a relatively important error to > > > acknowledge, because it most likely means that there is a bug in our code > > > somewhere. > > > > I meant when it is being used as a cleanup, rather than to close/free > > something. > > I guess I was thinking that the error message is just as important if we > are using the function as a cleanup. Our cleanup routines should have the > smarts required to output useful error messages, in time. Same example, I > am closing a file, because I am removing a context. I get APR_EBADF. > This should be reported somehow. Put a line in the error log that says > "Received APR_EBADF while executing cleanups." Honestly, we should not be > getting error codes during cleanups, and if we are, there is a bug > somewhere. I would personally like to know about it. That sounds like a plan. > > Because the cleanup may make slightly different assumptions (e.g. that > > everything else is about to get cleaned up, too). > > > > It makes sense, but I'm not sure I think it is a good idea. I'd rather > > have a third cleanup. I think. > > No offense Ben, you say you aren't sure it's wise, it doesn't sit right > with you, etc. Everytime I say anything like that, I get hammered for > hand waving over an issue. :) If you want to re-implement this, go > ahead, I won't complain. It is on the very bottom of my list right > now, because there is just too much work to be done in APR. :-) That's a fair comment. My specific concern is that the cleanup functions are designed to clean up _when a pool is destroyed_. Overloading that with releasing specific resources in the normal course of events strikes me both as a risk, in the sense that we may find one day that we really need all three semantics, and (potentially) an extra porting problem for modules moving from 1.x. Certainly it seems to me that there _are_ three different semantics, and squeezing them into two function calls may be something we come to regret. Cheers, Ben. > > Ryan > > _______________________________________________________________________ > Ryan Bloom rbb@raleigh.ibm.com > 4205 S Miami Blvd > RTP, NC 27709 It's a beautiful sight to see good dancers > doing simple steps. It's a painful sight to > see beginners doing complicated patterns. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi