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
