Re: [RFC] Additional context in pcntl_signal handler (was Re: [PHP-DEV] pcntl_signal & sa_siginfo)

On Thu, Jun 23, 2016 at 1:49 PM David Walker <dave@mudsite.com> wrote: > On Thu, Jun 23, 2016 at 12:26 PM Dmitry Stogov <dmitry@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 <dmitry@zend.com> >> *Sent:* Thursday, June 23, 2016 9:02:55 PM >> *To:* PHP internals; bishop@php.net; Joe Watkins; davey@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? >> > > > 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) > Having run tests through callgrind there is, as expected, a small bit of overhead. The question is, how much overhead can be safely deemed negligible for ease of the language? In my basic test wherein I just define an empty function, set the handler, and trigger the signal there is just over 13m instructions executed. This change increases the instruction count by about 2000, or 0.0001%. I would assume keeping a simple pcntl_signal() with a single handler is more desirable than mitigating the slight overhead this introduces. -- Dave