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

Afternoon, The last alpha is going out today. There will be two weeks before the first beta, which is feature freeze. Cheers Joe On Thu, Jul 7, 2016 at 3:20 PM, David Walker <dave@mudsite.com> wrote: > 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 >