apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: multithreaded pools?
Date Mon, 09 Jul 2001 06:45:00 GMT
On Sun, Jul 08, 2001 at 11:23:56PM -0700, dean gaudet wrote:
> On Sun, 8 Jul 2001, Roy T. Fielding wrote:
> 
> > The last time I looked at the pool code it was bogus because clean_child_exit
> 
> how can clean_child_exit ever hope to work in a multithreaded server
> without async notification?

It is only called when the child exits and not per-thread.  I think the
threads are already dead by that point, or locked-up due to some fatal
error that is the reason why clean_child_exit is being called.

> in particular, what happens when modules start creating their own thread
> pools within the server to do their own specific stuff?

I presumed they would be children of the per-thread root pool.

> i don't see how my change would make it any worse.  at least for the httpd
> threads you know how to tell them all to finish up and die, and on the way
> out they happen to destroy their pools.  so that handles all those new
> pool roots.  (i'm not sure if clean_child_exit does this at all
> currently.)

Oh, only worse in the sense that it adds more pools that are disconnected,
yet dependent upon, the global pool created during apr_initialize.  I just
think we should fix that bug first -- either connect them all or remove the
dependencies and make sure the cleanups still work.

> if clean_child_exit goes happily waltzing all over data in pools that are
> in use by other threads without first killing the other threads then we're
> just asking for segfaults, or even worse:  data corruption (such as
> calling a cleanup on something which was unregistered).  there's race
> conditions left and right.  you'd kind of have to lock everything
> always... and then you'd have to deal with deadlocks on the way out of
> clean_child_exit (not to mention a lack of performance).

I think it is only run after the threads are dead, but I don't know the
threaded code well enough to know if the threads are actually stopped
in a clean way or if it still assumes that the process can clean up
everything that the threads needed to clean.

The reason I said it was already broken is because the disconnected
pools meant that some of the subpools that were being automatically
cleaned-up on exit (because they descended from pglobal in 1.3) were
not being cleaned-up in 2.0.  Their cleanups simply weren't being called.
At least not as far as I could see (which wasn't all that far because the
threaded MPM code gives me a headache).

....Roy


Mime
View raw message