Re: [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).
| From: | Dmitry Stogov | Date: | Fri, 24 Jun 2016 16:05:57 +0000 |
| Subject: | Re: [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead). | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-94250@lists.php.net to get a copy of this message | ||
The INI setting can be changed at run-time through ini_set(). I'll update the RFC.
________________________________
From: Mike Willbanks <pencap@gmail.com>
Sent: Friday, June 24, 2016 6:50:59 PM
To: Dmitry Stogov
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional
overhead).
On Fri, Jun 24, 2016 at 5:20 AM, Dmitry Stogov <dmitry@zend.com<mailto:dmitry@zend.com>> wrote:
Hi internals,
Please review the RFC https://wiki.php.net/rfc/async_signals
I do not like the idea of introducing this via an INI directive, what might be of value is to have a
behavior on the function recommendation such that:
pcntl_async_signals([bool $enabled])
Without passing in the variable it could return back the current status (enabled or not). This
provides userland a far more flexible handling. The INI setting could cause some additional issues.
What is not clear is can the INI setting be changed at runtime - so additional clarification is
needed there. The main concern for this comes in when you build for multiple consumers and do not
control the environment. This can cause havok especially when you do need to have signals.
Thanks. Dmitry.