I agree with OtherBill.
Cleanups are not always the answer. When they are run, many things
associated with that pool could be torn down already because their cleanups
have already run.
If you need a known state to perform *operations* (as it sounds like Jon is
doing), then you can't use a cleanup.
Hooks are orderable, but more importantly: they run at a specified time. In
this case, before the pool is cleaned up.
Lingering close should not be part of the connection pool cleanup. It is a
specific action that needs to occur *before* we are done with the connection
pool. That is why Bill's suggestion of running it as a hook is great. It
also gives people a chance to perform actions relative to that close and
before pool cleanup occurs.
Cheers,
-g
On Tue, Sep 18, 2001 at 02:20:35PM -0500, William A. Rowe, Jr. wrote:
> From: "Ryan Bloom" <[EMAIL PROTECTED]>
> Sent: Tuesday, September 18, 2001 11:44 AM
>
>
> > On Tuesday 18 September 2001 08:17 am, William A. Rowe, Jr. wrote:
> > > Why not let the MPM register the lingerclose with APR_HOOK_MIDDLE in the
> > > post_connection hook? That way, if Jon's (or any other author's) intent is
> > > to work before the lingering close, then it can be APR_HOOK_FIRST.
> > > Otherwise register it APR_HOOK_LAST.
> >
> > It shouldn't be a hook. This should just be done with a pool cleanup. Hooks
> > aren't the answer to every problem in the server. Doing something after a
> > specific action, like the close of the connection should be done by registering
> > a pool cleanup. Fix the bug that you can't register a cleanup within a cleanup,
> > and Jon's problem goes away completely, because he can use the cleanup
> > that he is already using.
>
> The pool cleanup has one disadvantage (assuming the register cleanup within cleanup
> bug is fixed), the order of cleanups is a strict LIFO.
>
> There _may_ be an advantage to an orderable hook. At this point I agree, fix the
> register cleanup in cleanup bug, let Jon experiment with that solution, and then
> argue the merits for a new hook.
>
> Bill
--
Greg Stein, http://www.lyra.org/
