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) > > Hi, > > > 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? > Dmitry, 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 BC-problems. -- Dave
