Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:17172 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4229 invoked by uid 1010); 7 Jul 2005 22:56:31 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 4214 invoked from network); 7 Jul 2005 22:56:31 -0000 Received: from unknown (HELO pb1.pair.com) (127.0.0.1) by localhost with SMTP; 7 Jul 2005 22:56:31 -0000 X-Host-Fingerprint: 204.11.219.139 lerdorf.com Linux 2.4/2.6 Received: from ([204.11.219.139:59262] helo=colo.lerdorf.com) by pb1.pair.com (ecelerity 1.2 r(5656M)) with SMTP id 09/2C-59389-C13BDC24 for ; Thu, 07 Jul 2005 18:56:28 -0400 Received: from [192.168.2.106] (c-24-6-1-160.hsd1.ca.comcast.net [24.6.1.160]) (authenticated bits=0) by colo.lerdorf.com (8.13.4/8.13.4/Debian-3) with ESMTP id j67MuOlo026936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 7 Jul 2005 15:56:24 -0700 Message-ID: <42CDB318.5080206@lerdorf.com> Date: Thu, 07 Jul 2005 15:56:24 -0700 User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: internals@lists.php.net X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Signal handling cleanup proposal From: rasmus@lerdorf.com (Rasmus Lerdorf) Currently we have some issues when it comes to dealing with signals. We have a number of critical sections in the engine and in various extensions that rely on the HANDLE_BLOCK_INTERRUPTIONS macro in an attempt to not be interrupted. However, the actual signal blocking is supplied by the current SAPI and for Apache2, for example, the macro does nothing. So there is no critical section protection for PHP under Apache2 which is probably the cause of some of the weirder Apache2 problems we have been seeing. A secondary issue is that 3rd-party libraries can potentially install signal handlers which could bleed from one request to the next and do weird things. Having something install a handler for SIGUSR1 when we are running under Apache could cause some really weird results. So, here is a suggested solution to address both of these issues: php_defer_signals_init() This would save the list of handlers for the non-fatal async signals like SIGHUP, SIGINT, SIGQUIT, SIGTERM, SIGUSR1, and SIGUSR2 and install our own handler for each of these. our_own_handler() Check to see if the critical section flag is set or not, and if not would simply call the original handler for the signal as saved by the php_defer_signals_init() call. php_defer_signals_start() Increment critical section flag php_defer_signals_stop() Decrement critical section flag php_defer_signals_terminate() Uninstall our special handler and restore original handlers The big benefit here is that since we have a lot of critical sections per request, we don't need to install and remove handlers for every critical section which would translate to a lot of extra syscalls. Each critical section just twiddles a flag/counter. It would be really nice if we only had to call _init() on module startup and _terminate() on module shutdown, but I am not sure we can get away with that. At least in Apache it looks like they change the signal handler at the start of a request. We may be able to work around that though. -Rasmus