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.
Am 24.06.2016 um 12:20 schrieb Dmitry Stogov:
Please review the RFC https://wiki.php.net/rfc/async_signals
Would this alleviate the fact that ticks are broken in PHP 7? See
https://github.com/sebastianbergmann/phpunit/issues/2205 for what I use
ticks for in PHPUnit.
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
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
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
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.
Well, the code yes not the impact.
Morning,
How is the impact wider than ext/pcntl ?
Cheers
Joe
The proposed version of this RFC is 7.1, and the discussion wasstarted
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.Well, the code yes not the impact.
Morning,
How is the impact wider than ext/pcntl ?
The implementation is only in pctnl. The feature is used indirectly by
the engine and makes it a core feature. Quote from the RFC:
"Zend Engine in PHP 7.1 was extended with ability of safe time-out and
interrupt handling. Actually, PHP VM checks for EG(vm_interrupt) flag
on each loop iteration, user function entry or internal function exit,
and call callback function if necessary.
I propose to use this ability to implement asynchronous signal
handling. Registered signal handlers are going to be called at some
points during user script execution without any overhead."
and the test:
<?php
ini_set("pcntl.async_signals", "1");
pcntl_signal(SIGTERM, function ($signo) { echo "Signal handler called!\n"; });
echo "Start!\n";
posix_kill(posix_getpid(), SIGTERM);
$i = 0; // dummy
echo "Done!\n";
It affects how signals are handled within the engine, obvioulsy.
I have no doubt that this RFC will be accepted, by large, so it is not
a big issue. However it does affect the engine so the 2/3 rule
applies.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Morning,
How is the impact wider than ext/pcntl ?The implementation is only in pctnl. The feature is used indirectly by
the engine and makes it a core feature. Quote from the RFC:"Zend Engine in PHP 7.1 was extended with ability of safe time-out and
interrupt handling. Actually, PHP VM checks for EG(vm_interrupt) flag
on each loop iteration, user function entry or internal function exit,
and call callback function if necessary.I propose to use this ability to implement asynchronous signal
handling. Registered signal handlers are going to be called at some
points during user script execution without any overhead."and the test:
<?php
ini_set("pcntl.async_signals", "1");
pcntl_signal(SIGTERM, function ($signo) { echo "Signal handler called!\n"; });echo "Start!\n";
posix_kill(posix_getpid(), SIGTERM);
$i = 0; // dummy
echo "Done!\n";It affects how signals are handled within the engine, obvioulsy.
I have no doubt that this RFC will be accepted, by large, so it is not
a big issue. However it does affect the engine so the 2/3 rule
applies.
We use 2/3 vote for "a feature affecting the language itself (new syntax
for example)", not the engine internals.
Pierre,
> It affects how signals are handled within the engine, obvioulsy.
How signals are handled in the engine was already changed, the only
thing being proposed here is that ext/pcntl uses that new feature.
Cheers
Joe
On Mon, Jun 27, 2016 at 5:08 PM, Joe Watkins pthreads@pthreads.org
wrote:Morning,
How is the impact wider than ext/pcntl ?The implementation is only in pctnl. The feature is used indirectly by
the engine and makes it a core feature. Quote from the RFC:"Zend Engine in PHP 7.1 was extended with ability of safe time-out and
interrupt handling. Actually, PHP VM checks for EG(vm_interrupt) flag
on each loop iteration, user function entry or internal function exit,
and call callback function if necessary.I propose to use this ability to implement asynchronous signal
handling. Registered signal handlers are going to be called at some
points during user script execution without any overhead."and the test:
<?php
ini_set("pcntl.async_signals", "1");
pcntl_signal(SIGTERM, function ($signo) { echo "Signal handler
called!\n"; });echo "Start!\n";
posix_kill(posix_getpid(), SIGTERM);
$i = 0; // dummy
echo "Done!\n";It affects how signals are handled within the engine, obvioulsy.
I have no doubt that this RFC will be accepted, by large, so it is not
a big issue. However it does affect the engine so the 2/3 rule
applies.We use 2/3 vote for "a feature affecting the language itself (new syntax
for example)", not the engine internals.
hi,
Hi internals,
Please review the RFC https://wiki.php.net/rfc/async_signals
Travis is not happy in ZTS, can you check please?
https://travis-ci.org/php/php-src/jobs/139981256
--
Pierre
@pierrejoye | http://www.libgd.org