Philippe M. Chiasson wrote:
You've forgotten to reply to this part.Sorry, but you didn't understand what I was trying to say. Let's say you have only one process with many threads. If that process grows too big (since you can't measure a size of a thread) it'll throw the TERM signal and then it'll block until all threads are done. Meanwhile no other new requests will be started. Or will the parent process spawn a new process as soon as its child receives SIGTERM? I can't see how the parent will know about it, before the child terminates.
Yes, the situation you just described is correct. In the case of one child and multiple threads, sending a SIGTERM is not a very good idea.
But this is exactly the same situation with N child processes. It's quite possible that all N processes will get SIGTERM in about the same time.
Once again, we can just go the original way and support this _only_ for non-threaded MPMs. Would work perfectly fine for prefork, and
wouldn't need to call exit() directly or to mess around trying to push a pool cleanup handler and insure its the last cleanup to get run.
You mean just exit()? What original way?
Oh, it's definitely better if we can get an ap_ api for this, and I am plannnig on either writing on or at least pigningSo may be there is a need to expose it via a proper ap_ api?
the folks at httpd-dev about it. I was merely proposing a suggestion that might just fit our needs for now, while we
are looking for the best solution.
using a api call vs. signals is not the same thing, so I'm not sure it's a good temporary solution in case we are going to have a proper api call.
In my opinon, the here are the various solutions in order of preference 1. Call an ap_* function 2. Send a SIGTERM 3. Call exit() directly
And most likely, 2 & 3 only make sense for non-threaded MPMs
Right.
OK, so anybody wants to start this thread to httpd-dev before we decide how to handle it with mod_perl?
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
