Philippe M. Chiasson wrote: [...]
Second, you will get a child that gets to cleanly shutdown, however the child chooses to do that.
like what?
I just meant that calling exit() by ourselves is possibly causing a child process to exit before having been
able to do various cleanup tasks a child does. Looking at the various mpm modules, I can see in worker,
for instance, a child wanting to update it's state in the scoreboard before shutting itself down.
How does it deal with processes that segfault? Does the scoreboard gets out of sync if there is a segfault and it still thinks that there are processes around, which are gone since long...
For a threaded MPM like prefork, we currently have no valid solution to
implement child_terminate() in order to reclaim memory. This way would at
least provide a partial solution. If a child grows to fat, calling $r->child_terminate()
would guarantee that that child will not serve new requests (keepalive issues exluded)
and kill itself off as soon as it can.
But it's very dangerous. Assume that you have N processes with M threads. If all processes will be scheduled to be killed, you will have a long long time w/o the server accepting any new requests.
No, no, only the child process will do that, the parent, and all the other
siblings will keep on hapilly serving requests.
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.
You've forgotten to reply to this part.
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.
-- __________________________________________________________________ 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]
