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