Morning internals,
The proposed version of this RFC is 7.1, and the discussion was started
very late. However, since this is a self contained change in an extension,
I'm not sure it needs a 2/3 majority, and I'm not sure that it needs a full
discussion/voting period.
So I'm happy for this to go into 7.1, if we can resolve the outstanding
question of configuration before voting commences, or as part of the vote.
The introduction of new ini entries is something we try to avoid, and
would be the only reason you could argue this requires a super majority
(although I think that argument invalid).
I think I prefer bob's idea to have a flag parameter on pcntl_signal:
* it avoids a new ini entry, and additional functions
* it gives a more granular control over execution
I'd like to see the implementation updated to use this approach and a
simple 50%+1 Yes/No vote, alternatively, include this as a voting option.
The vote needs to be opened by June 29th for a one week (minimum)
voting period.
Cheers
Joe
On Sun, Jun 26, 2016 at 3:14 PM, Bob Weinand <bobw...@hotmail.com> wrote:
>
> > Am 24.06.2016 um 12:20 schrieb Dmitry Stogov <dmi...@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
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
