On Sun, 8 Jul 2001, Roy T. Fielding wrote: [clean_child_exit] > > 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.
when you say "the threads are dead" you're referring to the httpd threads. there could be zillions of other threads started up by third party modules, still running. but also, if you look at the call sites within threaded.c you'll find that even the httpd threads are (potentially) still running. huh, at least one of the call sites -- where apr_thread_create fails looks like a genuine bug. exit the PROCESS if you can't create a thread, for any reason whatsoever? this is in start_threads. also, clean_child_exit is called when SIGTERM is received... and makes no attempt to stop the httpd threads. so basically clean_child_exit() really should just call exit() and avoid the possibility of damaging data by calling cleanups owned by other threads (and with no locking to protect them). ... anyhow, you've got issues with root pools coming out our ears. i can understand that. a solution which came up ages ago when we first talked about this was to register a "thread cleanup" in the parent. the thread cleanup is a link to the thread's root pool, and because it doesn't go through the usual parent/child relationship we can handle it specially (such as including locking while accessing it, this avoids hitting the fast path that we want there for all other sub pool create/destroys). now we just need to figure out how to get the thread to rendezvous with the parent and we can build a cleanup system that works :) while i am wholly against async notification, i'm not at all against a unified method of synchronous notification -- a flag somewhere in the per-thread data indicating "please stop at your earliest convenience". but i'm still not sure this is useful for clean_child_exit -- clean_child_exit is a lot like the debate about abort() within apr_palloc. something is royally screwed when this happens, and there's really nothing graceful you can do... i believe the safest thing is to call exit() as fast as possible without stopping to try to do anything fancy. -dean
