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 > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
