httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: [PATCH] Serialize the update to pool.sub_* in destroy_pool
Date Tue, 16 Dec 1997 00:18:33 GMT
Dean Gaudet wrote:
> 
> On Mon, 15 Dec 1997, Ben Laurie wrote:
> 
> > Dean Gaudet wrote:
> > > This breaks down though on timeouts when the longjmp happens to clean
> > > up everything.  In that case the three subthreads need to be cleaned
> > > up before their pools can be.  Unfortunately, clear_pool() recurses to
> > > the deepest pool first before doing a run_cleanups(), and so it would
> > > try to clean up other_sub_pool before it had run the cleanup that would
> > > kill off the three subthreads.
> > >
> > > Aha.  Do other_sub_pool = make_sub_pool(NULL), and then take care of
> > > that with a cleanup registered in pool1.
> >
> > Glurp. And then if you destroy the subpool you need to also destroy the
> > cleanup. Presumably you need to serialise this cleanup, too.
> 
> Right, but the sub pool is only destroyed by the cleanup, and that cleanup
> also destroys the thread(s) that were using the sub pool.  Serialization
> is implicit because the other threads are gone.

I meant serialise the destruction of the cleanup. Not quite sure about
that, though. Guess it depends on circumstances.

> > Perhaps it would be more elegant to have "top down" cleanups which get
> > executed before the (existing) "bottom up" cleanups? Thread cleanups
> > would then be "top down" and, well, presto.
> 
> Yeah I've wondered about this myself at one point too -- but I've been
> able to come up with solutions using the current stuff so far.  But I've
> had to assume that the current implementation of alloc.c is the documented
> API.  That is, cleanups occur after sub pools are destroyed, and cleanups
> occur in the reverse order they're registered in.

Let's document it and introduce top-down cleanups. Simplicate and add
lightness, I say.

The order of cleanups is important. People shouldn't have to assume
things about them.

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Mime
View raw message