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
I'd like to take a step back and try and understand better in which cases
we are failing. Although I know we added critical section code in the hash,
I think it's effectiveness is questionable, because I believe there are
many places today where we might have critical sections besides the hash
which we aren't protecting.
(And I agree with you that protecting them with real system calls sucks).
Can you describe what problems you are encountering?
Thanks,
Andi
At 03:56 PM 7/7/2005 -0700, Rasmus Lerdorf wrote:
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