Signal handling cleanup proposal

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