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
