Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17178
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20050707170112.027d80a0@localhost>
Date: Thu, 07 Jul 2005 17:08:02 -0700
To: Rasmus Lerdorf <rasmus@lerdorf.com>,internals@lists.php.net
In-Reply-To: <42CDB318.5080206@lerdorf.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Signal handling cleanup proposal
From: andi@zend.com (Andi Gutmans)
References: <42CDB318.5080206@lerdorf.com>

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
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php