Geoffrey Young wrote:
The keyword is the "not immediately" -- that solution will make Apache::SizeLimit and its clones unreliable. Since you will never be able to bracket the memory usage again.
That's incorrect. You will be able to bracket memory usage. In a prefork MPM, calling $r->child_terminate() will kill off that child as soon as the current request is done with, after running cleanups et all.
OK, so what's the difference from calling exit?
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.
Ofcourse the apache 1.3 api was calling child_terminate at the end of the request, so it wasn't immediate either, but it was guaranteed to be called asap. I believe with signals it's totally unreliable.
No, it's about as reliable as apachectl restart/gracefull will kill off the childs.
but we aren't trying to call 'graceful restart'
in 1.3 ap_child_terminate just sets MaxRequestsPerChild to 0, leaving apache
to reap the child at the end of the current request.
Yup, I looked at that, but in 2.0, at the beginning of the lifetime of a child,
a private counter is set to MaxRequestsPerChild and decremented for each request.
Child termination is caused when that number reaches zero. So, changing MaxRequestPerChild
will not work that way anymore.
So any chance we can get hold of that counter?
-- __________________________________________________________________ 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]
