handle fastcgi signals
authorMischa POSLAWSKY <perl@shiar.org>
Wed, 7 May 2008 17:53:50 +0000 (17:53 +0000)
committerMischa POSLAWSKY <perl@shiar.org>
Wed, 28 May 2008 10:07:30 +0000 (10:07 +0000)
commit0836519b627579b7edd0ec6527f75344e0527bd4
tree4a59392dfa0c85bbf436680f69fd9db3b0518f40
parent5d65ad9b409494bb4e7c98a27d29079e09b111f5
handle fastcgi signals

http://www.fastcgi.com/devkit/doc/fcgi-spec.html#S7
> A Web server can request that a FastCGI application exit by sending it
> SIGTERM. If the application ignores SIGTERM the Web server can resort
> to SIGKILL.

So stop accepting new requests after receiving a TERM signal.  Allow the
current page to finish, we should assume it won't be long (long-running
scripts usually require customized destructors anyway, so don't account
for those).  This is quite important to prevent interrupted output.

According to http://www.fastcgi.com/docs/faq.html#Signals Apache
mod_fastcgi will send a SIGUSR1 in addition to the TERM.  Seems safe to
ignore these.

If a client aborts a connection, we'll get a SIGPIPE.  Because the page
may still have crucial actions to perform, we should ignore and finish
the code.  Pages can easily handle PIPEs themselves if wanted.

The LastCall method is used, even though FCGI 0.67 warns:
> Note that this method is still experimental and everything about it,
> including its name, is subject to change.

As it's stable since september 2001, I guess it'll be fine for now.
PLP/Backend/FastCGI.pm