Stas Bekman wrote:
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. 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.
in 1.3 ap_child_terminate just sets MaxRequestsPerChild to 0, leaving apache to reap the child at the end of the current request. however, there is a bug/feature in the way 1.3 calculates "current request" - it really means (in this case) "current connection" if keepalives are involved. so, calling $r->child_terminate in 1.3 terminates a child process after that child is through processing the connection, which may be several requests after the call is actually made.
just FYI.
That makes sense. Thanks for the heads up, Geoff.
Any way we can mess with MaxRequestsPerChild in the same way
Like I said in another mail to Geoff, the way the MPM are implementing MaxRequestsPerChild tracking make that approach impossible currently.
Had anyone asked this question on the httpd-dev list? Or did I miss that discussion?
Nah, just that for performance reasons (I imagine), the value of MaxRequestPerChild is only used at child startup time to setup a private decrementing lifetime counter.
-- -------------------------------------------------------------------------------- Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
signature.asc
Description: OpenPGP digital signature
