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.

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.

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.


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.

 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.

Yes, and that's a must, since you can't just terminate cleanly and kill off an open connection to a client that's waiting in keepalive waiting to send another request.

just FYI.

--Geoff

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-- -------------------------------------------------------------------------------- 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

Attachment: signature.asc
Description: OpenPGP digital signature



Reply via email to