On Tuesday 05 August 2008 08:51:33 Arnaud Le Blanc wrote: > Votre message: > > Greetings! > > > > On 8/3/08 9:37 PM, "Arnaud LB" <[EMAIL PROTECTED]> wrote: > > > If sigaction is not available Zend Signal Handling will not be > > > enabled, so it will not be enabled on Windows (I assume sigaction is > > > not available on Windows, it is ?). > > > For pthreads and sigprocmask, tsrm_sigmask() can be improved to add > > > support for other APIs. However it seems that only pthread provides > > > that. Apache/APR relies on phtread_sigmask() when available, or > > > sigprocmask() when not. > > > > Ahh correct. Wasn't looking at this correctly. As for non pthread > > sigprocmask sounds like we'll find out if it's problematic in any way. > > Good to know this is at least what apr is doing. > > > > >> If in the future we have anything in the stack registering a signal > > handler > > > >> via zend_signal this will be problematic because SIGG_*_CRITICAL > > >> sections will not cover the signals registered post-startup. > > > > > > sigaction() is process-wide, so if a thread registers a signal > > > post-startup (this is already the case, zend_sigs[] are registered at > > > request-startup) the signal will be defered in all threads :) > > > > The deferring will basically work in the new model but I'm relying on > > sigprocmask(SIG_BLOCK/SIG_SETMASK) in the SIGNAL_CRITICAL macro's to > > protect against jumps during queue maintenance and in > > zend_signal_handler_unblock when it calls zend_signal_handler_defer. If a > > post startup signal is registered, the latest version of zend_signal > > doesn't add the new signal number to the mask, it only sets sa_mask to > > globals_sigmask. If we add the registered signal to the global_sigmask > > before setting sa_mask here then I think we would be ok. > > global_sigmask is initialized using sigfillset(), so it contains _all_ > signals (except SIGSEGV, etc because non-blockable or not safe to block) > and there is no need to add signals to global_sigmask it in zend_signal() / > zend_signal_register() :) > > > >> I originally did not use an array as I was hoping to dynamically > > >> allocate more queue at runtime. I hadn't fully thought it out because > > >> there are almost no calls into the code where this would be > > >> apropriate. We could > > maybe > > > >> do something in zend_signal_handler_unblock but it might be too late > > there > > > >> and with this it would not be possible. I don't think I have a problem > > with > > > >> this though. > > >> Not that it won't happen but I can't imagine a scenario where we get > > >> hammered with more signals than we would have slots in > > >> ZEND_SIGNAL_QUEUE_SIZE and it wouldn't be safe to ignore them. At > > >> least > > with > > > >> the signals we're handling out of the box. This could change when we > > >> get pcntl working with this. > > > > > > Yes, it may be great to be able to grow the queue when necessary. > > > > I'll make a note in the considerations section of the wiki that when we > > get zend_signal ready to hook up to pctnl we'll reconsider the static > > allocation. > > For extensions IMO we should just let them use zend_signal() as it > currently is. Using pcntl_signal() will override handlers previously set by > zend_signal() but the signal will remain deferred. > > I was also thinking to implement zend_sigaction(), allowing to know the > previously registered signal, and to set some flags when registering signal > handlers. > > > -lucas
I updated the patches on the wiki: - Added zend_sigaction() - Ported PCNTL to use zend_sigaction() - Fixed handling of SIG_IGN Regards, Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
