apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] fix cleanups in cleanups
Date Fri, 21 Sep 2001 03:30:07 GMT
From: "Aaron Bannert" <aaron@clove.org>
Sent: Thursday, September 20, 2001 10:12 PM

> On Thu, Sep 20, 2001 at 05:48:45PM -0700, Greg Stein wrote:
> > On Thu, Sep 20, 2001 at 11:18:55AM -0700, Aaron Bannert wrote:
> > >...
> > > Does this fix it for you? All testmem tests passed for me and your code
> > > above properly flushes "Cleanup" to the file.
> > > 
> > > (Someone needs to check my work on run_child_cleanups() and make sure
> > > that the popping is necessary. It looked to be in the same situation.)
> > 
> > Calling pop_cleanup() on every iteration is a bit much. Consider the
> > following patch:
> The reason I went that route, instead of just inlining the pop_cleanup()
> code is that it gets called in two places. If it is a performance issue,
> I'd just put it all inside the while loop in run_cleanups(). Would
> that be preferable?

Aaron, you were right on here.  If I'm in a cleanup, which has to create an
apr_foo entity on the same pool, when I'm done with my cleanup, that new
cleanup added by apr_foo should be called _next_.  So it's not overkill to
treat this as a pure stack.

> > Basically, the above code processes the cleanups in batches. Everything that
> > was initially registered is processed, then everything registerd during the
> > first cleanup round, etc.
> That does encourage deeper recursion, would this be a potential problem
> for OSs like Netware that have a rather small and limited stack size?
> I don't really know how much the pool_clear() routines consume stack space.

This actually sounds cyclically hazerdous.  (not that the other cleanup couldn't
suffer the same, if three different cleanups kept registering one another, round
robin style, by creating objects of each other.)

I'd rather stay very clean, and know that everything in existance when a cleanup
is registered may still exist when that cleanup is called.  This 'batching'
appears too hazerdous, from that perspective.

> > It does not maintain the LIFO behavior where cleanup A registers cleanup B
> > and expects B to run *just after* cleanup A finishes. If A wanted that, then
> > it could just calll B. But the most important part: all cleanups *do* get
> > run.
> Correct me if I'm wrong, it is a LIFO and what Ryan wants is a FIFO.
> LIFO == cleanup registers a cleanup, it gets run after the cleanups
> FIFO == cleanup registers a cleanup, it gets run as soon as this one returns
> Am I missing something?

Yes, FIFO = cleanup registers a cleaup, it was the _last_ one registered, so it
would be cleaned up last.  That's exactly what we don't want.

LIFO = cleanup registers a cleanup, it is the _last_ one registered, it is the
first one cleaned off (even if we are in the processing of running the list of
cleanups as it was registered.)


View raw message