On Thu, Jun 23, 2016 at 12:26 PM Dmitry Stogov <dmi...@zend.com> wrote:
> BTW: I'm not sure what pcntl_sigaction() could return as the "oldact"
> argument..., so may be the original proposal is good enough.
> *From:* Dmitry Stogov <dmi...@zend.com>
> *Sent:* Thursday, June 23, 2016 9:02:55 PM
> *To:* PHP internals; bis...@php.net; Joe Watkins; da...@php.net
> *Cc:* David Walker
> *Subject:* Re: [PHP-DEV] [RFC] Additional context in pcntl_signal handler
> (was Re: [PHP-DEV] pcntl_signal & sa_siginfo)
> To keep maximum compatibility and eliminate unnecessary additional
> overhead, I would keep pcntl_signal() unchanged, but add pcntl_sigaction()
> with the ability to specify the need for the second argument (In the same
> way as POSIX does).
> Joe, Davey, when we stop targeting new RFCs for 7.1?
I was thinking about making a separate pcntl_* method to handle the
differences, but decided against doing it as i assumed that the overhead
involved in a siginfo_t allocation would be marginal. Having a separate
call, if everyone would prefer, wouldn't be hard to implement. Now, this
being my first attempt at contributing to internals, I'm not well versed on
a best-practices on benchmarking to provide metrics to my assumption.
(advice very welcomed)
On your second point, it's interesting you discuss the *oact. As it is
today, calls to pcntl_signal() define the C level signal_handler
as pcntl_signal_handler. So the *oact is always going to be the same
handler, since userland can't control the C level handler. However, a
similar idea was brought up in 72409 <https://bugs.php.net/bug.php?id=72409> to
have the userland callable returned. I took a stab at that bug with this
pullreq <https://github.com/php/php-src/pull/1952> so that the callable a
user sets to a signal would be returned. I wasn't sure if it was PR-able,
since it changes a return value of a method, and would have some