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 <d...@mudsite.com> wrote:
> On Thu, Jun 23, 2016 at 1:49 PM David Walker <d...@mudsite.com> wrote:
>
>> 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?
>>>
>>
>>
>> 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
>
