httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: APR cleanup status?
Date Mon, 13 Sep 1999 20:00:03 GMT
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



> Ryan
> _______________________________________________________________________
> Ryan Bloom    
> 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.


"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

View raw message