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

Mike Willbanks

10 years ago

On Fri, Jun 24, 2016 at 5:20 AM, Dmitry Stogov <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.

Dmitry Stogov

10 years ago

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.

Sebastian Bergmann

10 years ago

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.

Dmitry Stogov

10 years ago

I don't know what is broken

________________________________
From: Sebastian Bergmann <sebastian@php.net>
Sent: Sunday, June 26, 2016 8:27:12 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Bob Weinand

10 years ago

> 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

Joe Watkins

10 years ago

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 <bobwei9@hotmail.com> wrote:

Pierre Joye

10 years ago

On Jun 27, 2016 1:20 PM, "Joe Watkins" <pthreads@pthreads.org> wrote:

>     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.

Joe Watkins

10 years ago

Morning,

How is the impact wider than ext/pcntl ?

Cheers
Joe

On Mon, Jun 27, 2016 at 7:49 AM, Pierre Joye <pierre.php@gmail.com> wrote:

Pierre Joye

10 years ago

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.

Cheers,

--
Pierre

@pierrejoye | http://www.libgd.org

Dmitry Stogov

10 years ago

On 06/27/2016 02:05 PM, Pierre Joye wrote:

> 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.

https://wiki.php.net/RFC/voting#voting

Joe Watkins

10 years ago

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 12:28 PM, Dmitry Stogov <dmitry@zend.com> wrote:

Pierre Joye

10 years ago

hi,

On Fri, Jun 24, 2016 at 5:20 PM, Dmitry Stogov <dmitry@zend.com> wrote:

> 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

Dmitry Stogov

10 years ago

Everything fine now.

________________________________
From: Pierre Joye <pierre.php@gmail.com>
Sent: Tuesday, June 28, 2016 5:39:08 AM
To: Dmitry Stogov
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

hi,

On Fri, Jun 24, 2016 at 5:20 PM, Dmitry Stogov <dmitry@zend.com> wrote:

> 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