Re: [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

> Am 24.06.2016 um 12:20 schrieb Dmitry Stogov <dmitry@zend.com>: > > Hi internals, > > > Please review the RFC https://wiki.php.net/rfc/async_signals > > > Thanks. Dmitry. Overall, I really like the approach. I've thought a bit about the function vs. ini approach. Advantage INI: - Global setting, set it once, works everywhere Advantage function: - You are guaranteed one specific initial value and don't see surprises when one environment doesn't match your default and you forgot to explicitly enable/disable it. The former one is good when you have your own scripts everywhere on the server, the latter is preferable when you are installing external applications. An alternative approach would be adding a flag to pcntl_signal() whether it should be dispatched asynchronously or held back for synchronous dispatching (with async being the default). I prefer that third option because of the following scenario: a phpunit test with timeout testing an event loop. Event loops naturally want to enable synchronous dispatching, which obviously will hold back the signal and thus the alarm set up by phpunit will never be triggered if the test ends up in e.g. an infinite loop. I'm not convinced by this solution, but it's the best one I can think of solving all the cases. Bob