On Thu, Sep 20, 2001 at 07:02:58AM -0700, Ryan Bloom wrote:
> On Wednesday 19 September 2001 02:21 pm, Greg Stein wrote:
>...
> > They are not strictly LIFO. You can remove a cleanup and insert a new one
> > at any time. Let's say that the cleanup list looked like:
> >
> > cleanups: A
> >
> > and you add a new one to the "front":
> >
> > cleanups: B A
> >
> > and now case 1, where A needs to rejigger its cleanup param a bit:
> >
> > cleanups: A' B
> >
> > or case 2, where A simply removes its cleanup:
> >
> > cleanups: B
> >
> >
> > Case 2 actually happens quite often.
>
> This is all true, but it is also orthogonal to this conversation.
Partly. The conversation moved into "what can you do in a cleanup". If you
want to look at the simple issue of registering cleanups... okay. But when
people were expecting to be able to do "anything" in a cleanup... that is
intrinsically incorrect.
> The question we are
> trying to answer here, is can you register a cleanup within a cleanup.
Aaron posted a patch, but it introduces too many function calls in the
processing. I posted one that is much more optimal, processing the cleanups
in batches. That would fix your issue.
> If we are in
> the middle of running the cleanups, and somebody actually calls cleanup_run
> or cleanup_kill from within a cleanup, they are broken and it may not work.
My above case wasn't talking about doing those from within a cleanup (which
is definitely and always wrong). I was showing how the cleanups could be
reordered; therefore, how you cannot depend upon particular cross-cleanup
ordering dependencies. Thus, you are actually somewhat limited in what kinds
of things you can truly do in a cleanup.
> It also doesn't make any sense, because the reason to run a cleanup, is to perform
> some action sooner than you would have otherwise, but in this case, we are going
> to perform that action in a few seconds anyway.
I don't get this part. A cleanup is to do just that: clean up after yourself
when the pool goes away. It provides a point in time for specific types of
actions. I'm not sure how that gives you "sooner"; if anything, a cleanup is
for running things later.
> Since the two cases above require a programer to either remove or run a cleanup,
> they don't really make sense in the context of registering a cleanup within a
>cleanup.
> This means that is safe to register a cleanup within a cleanup, assuming the code
> is patched correctly.
Agreed. My point was addressing the "arbitrary work in a cleanup" meme that
was brought up.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
