On 2 January 2018 at 10:43, Anatol Belski <ab@php.net> wrote:
> Hi,
>
> > -----Original Message-----
> > From: Anatol Belski [
mailto:weltling@outlook.de] On Behalf Of Anatol
> Belski
> > Sent: Saturday, December 16, 2017 3:03 PM
> > To:
internals@lists.php.net
> > Cc: Niklas Keller <
me@kelunik.com>
> > Subject: [PHP-DEV] High resolution timer function
> >
> > Hi,
> >
> > I would like to propose a function for high resolution monotonic timing.
> There
> > was discussions about this before and a PR
https://github.com/php/php-
> > src/pull/2368 which has issues and was abandoned. I've filed
> >
https://github.com/php/php-src/pull/2976 with some reworked
> > implementation.
> >
> > A monotonic timer can be usable in several situations besides
> benchmarking.
> > Having a simple functionality like this in the core should be a useful
> addition. The
> > current approach is a function returning array of [seconds, nanoseconds]
> and
> > optionally returning full nanosecond number as int on 64-bit or float on
> 32-bit.
> > The first way is the most portable. Quite a few platforms are already
> supported
> > by the current implementation.
> >
> > IMHO it should be fine to have a function like this in the core, perhaps
> also a few
> > helper functions could be useful, too. I would like to pursue 7.3 with
> this. Please
> > lets check for any concerns in general or with implementation, naming,
> etc.
> >
> If there are no further comments or objection, I would like to merge this
> patch anytime soon and see to add a couple of helper functions for
> diff/compare.
>
>
Why is this bypassing the RFC process?
> Regards
>
> Anatol
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit:
http://www.php.net/unsub.php
>
>
Hi,
> -----Original Message-----
> From: Peter Cowburn [
mailto:petercowburn@gmail.com]
> Sent: Tuesday, January 2, 2018 2:56 PM
> To: Anatol Belski <
ab@php.net>
> Cc:
internals@lists.php.net; Niklas Keller <
me@kelunik.com>
> Subject: Re: [PHP-DEV] RE: High resolution timer function
>
>
>
> On 2 January 2018 at 10:43, Anatol Belski <
ab@php.net <
mailto:ab@php.net> >
> wrote:
>
>
> Hi,
>
> > -----Original Message-----
> > From: Anatol Belski [
mailto:weltling@outlook.de
> <
mailto:weltling@outlook.de> ] On Behalf Of Anatol Belski
> > Sent: Saturday, December 16, 2017 3:03 PM
> > To:
internals@lists.php.net <
mailto:internals@lists.php.net>
> > Cc: Niklas Keller <
me@kelunik.com <
mailto:me@kelunik.com> >
> > Subject: [PHP-DEV] High resolution timer function
> >
> > Hi,
> >
> > I would like to propose a function for high resolution monotonic
> timing. There
> > was discussions about this before and a PR
>
https://github.com/php/php-
> > src/pull/2368 which has issues and was abandoned. I've filed
> >
https://github.com/php/php-src/pull/2976
> <
https://github.com/php/php-src/pull/2976> with some reworked
> > implementation.
> >
> > A monotonic timer can be usable in several situations besides
> benchmarking.
> > Having a simple functionality like this in the core should be a useful
> addition. The
> > current approach is a function returning array of [seconds,
> nanoseconds] and
> > optionally returning full nanosecond number as int on 64-bit or float
> on 32-bit.
> > The first way is the most portable. Quite a few platforms are already
> supported
> > by the current implementation.
> >
> > IMHO it should be fine to have a function like this in the core, perhaps
> also a few
> > helper functions could be useful, too. I would like to pursue 7.3 with
> this. Please
> > lets check for any concerns in general or with implementation,
> naming, etc.
> >
> If there are no further comments or objection, I would like to merge this
> patch anytime soon and see to add a couple of helper functions for
> diff/compare.
>
>
>
>
> Why is this bypassing the RFC process?
>
The functionality is obvious and won't cause any BC issues. It was requested several times in the past, the patch was around for quite some time in several versions. Smaller pieces don't always require RFC. If there's no consent on ML, the RFC is required. That's where I stood, at least. The spared effort can be invested in some other areas. Is there some concrete concern on your side, about the implementation, etc.? I'd be glad to hear any feedback, can go for RFC, too.
Regards
Anatol
On 2 January 2018 at 13:55, Peter Cowburn <petercowburn@gmail.com> wrote:
>
>
> Why is this bypassing the RFC process?
That's a very good question.
Although I'm pretty sure an RFC for this would pass unanimously, stuff
should have to go through voting rather than relying on no-one
shouting loudly enough.
cheers
Dan
On 5 January 2018 at 10:38, Dan Ackroyd <danack@basereality.com> wrote:
> On 2 January 2018 at 13:55, Peter Cowburn <
petercowburn@gmail.com> wrote:
> >
> >
> > Why is this bypassing the RFC process?
>
> That's a very good question.
>
> Although I'm pretty sure an RFC for this would pass unanimously, stuff
> should have to go through voting rather than relying on no-one
> shouting loudly enough.
>
Just as a counter-point to this, I understand that many (Westminster
style?) parliaments have mechanisms to skip uncontroversial votes by first
requiring a show of hands or voices, and only "dividing the house" (making
everyone get up and register their formal votes) if there is dissent.
I think Anatol's intent here is similar: if anyone says "Nay", we can
proceed with an RFC and vote; but if it's already unanimous, why spend the
time, when we could be moving onto other business?
Regards,
--
Rowan Collins
[IMSoP]
Definitely. Small, uncontroversial changes have never required an RFC.
Let's not add process just for the sake of process.
-Rasmus
On Fri, Jan 5, 2018 at 3:47 AM, Rowan Collins collins@gmail.com>
wrote:
> On 5 January 2018 at 10:38, Dan Ackroyd <
danack@basereality.com> wrote:
>
> > On 2 January 2018 at 13:55, Peter Cowburn <
petercowburn@gmail.com>
> wrote:
> > >
> > >
> > > Why is this bypassing the RFC process?
> >
> > That's a very good question.
> >
> > Although I'm pretty sure an RFC for this would pass unanimously, stuff
> > should have to go through voting rather than relying on no-one
> > shouting loudly enough.
> >
>
>
> Just as a counter-point to this, I understand that many (Westminster
> style?) parliaments have mechanisms to skip uncontroversial votes by first
> requiring a show of hands or voices, and only "dividing the house" (making
> everyone get up and register their formal votes) if there is dissent.
>
> I think Anatol's intent here is similar: if anyone says "Nay", we can
> proceed with an RFC and vote; but if it's already unanimous, why spend the
> time, when we could be moving onto other business?
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
Hi Rasmus,
> -----Original Message-----
> From: Rasmus Lerdorf [
mailto:rasmus@lerdorf.com]
> Sent: Friday, January 5, 2018 5:42 PM
> To: Rowan Collins
collins@gmail.com>
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] RE: High resolution timer function
>
> Definitely. Small, uncontroversial changes have never required an RFC.
> Let's not add process just for the sake of process.
>
That was my premise, too, similar to what Rowan's second mail expressed. I myself didn't think it would be something big to vote, just to make lists aware. The PHP interface might be a subject to nitpick, but otherwise it's a long requested feature. I'm still to the QA of the patch, the PHP interface is still choosable of course, the functionality itself is to the big part ready.
Thanks.
Anatol
> -Rasmus
>
> On Fri, Jan 5, 2018 at 3:47 AM, Rowan Collins
collins@gmail.com>
> wrote:
>
> > On 5 January 2018 at 10:38, Dan Ackroyd <danack@basereality.com> wrote:
> >
> > > On 2 January 2018 at 13:55, Peter Cowburn <petercowburn@gmail.com>
> > wrote:
> > > >
> > > >
> > > > Why is this bypassing the RFC process?
> > >
> > > That's a very good question.
> > >
> > > Although I'm pretty sure an RFC for this would pass unanimously, stuff
> > > should have to go through voting rather than relying on no-one
> > > shouting loudly enough.
> > >
> >
> >
> > Just as a counter-point to this, I understand that many (Westminster
> > style?) parliaments have mechanisms to skip uncontroversial votes by first
> > requiring a show of hands or voices, and only "dividing the house" (making
> > everyone get up and register their formal votes) if there is dissent.
> >
> > I think Anatol's intent here is similar: if anyone says "Nay", we can
> > proceed with an RFC and vote; but if it's already unanimous, why spend the
> > time, when we could be moving onto other business?
> >
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
> >
Hi,
> -----Original Message-----
> From: Anatol Belski [
mailto:weltling@outlook.de] On Behalf Of Anatol Belski
> Sent: Saturday, January 6, 2018 12:31 AM
> To: Rasmus Lerdorf <
rasmus@lerdorf.com>; Rowan Collins
>
collins@gmail.com>
> Cc: internals@lists.php.net
> Subject: RE: [PHP-DEV] RE: High resolution timer function
>
> Hi Rasmus,
>
> > -----Original Message-----
> > From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
> > Sent: Friday, January 5, 2018 5:42 PM
> > To: Rowan Collins collins@gmail.com>
> > Cc: internals@lists.php.net
> > Subject: Re: [PHP-DEV] RE: High resolution timer function
> >
> > Definitely. Small, uncontroversial changes have never required an RFC.
> > Let's not add process just for the sake of process.
> >
> That was my premise, too, similar to what Rowan's second mail expressed. I
> myself didn't think it would be something big to vote, just to make lists aware.
> The PHP interface might be a subject to nitpick, but otherwise it's a long
> requested feature. I'm still to the QA of the patch, the PHP interface is still
> choosable of course, the functionality itself is to the big part ready.
>
This patch was merged a short while ago. Since then, a concern was raised on the PR page https://github.com/php/php-src/pull/2976#issuecomment-355882740 , that providing a high resolution timer could have impacts to shared hostings with regard to the Spectre vulnerability. The paper https://spectreattack.com/spectre.pdf describes a reproduce way in Javascript, which is why current browsers already issued a patch to reduce the timer resolutions as a part of mitigation. In further in the PR, it was suggested to provide a separate function that only cares about the monotony, but delivers time as milliseconds.
Now, as one can see in the paper, Javascript can provide an attack vector, because it compiles to JIT and because browsers provide certain features. Neither of those are currently available in PHP. Furthermore, PHP itself as any other program is vulnerable to Meltdown/Spectre and a proper fix is only available on the OS and hardware levels. Both features, high resolution and monotonic timer was requested earlier also not only those that led to this PR.
As it is now a few days after the disclosure, it is not quite clear how much impact high resolution timers might have on the PHP side in the future. At least, it doesn't seem obvious these issues are something to be fixed on the PHP side. For now, my suggestion were to keep hrtime() in the core and to implement monotonictime() that provides millisecond resolution. I'm working on that right now. If later on it turns out, that high resolution timers are a general security impact, parts regarding gettimeofday and microtime would have to be touched, too. But the monotonic low resolution timer would still have no impact, at least by today's knowledge. The Meltdown/Spectre issue is definitely something, that needs to be monitored with the regard to impacts to PHP.
Regards
Anatol
>
>
> > -Rasmus
> >
> > On Fri, Jan 5, 2018 at 3:47 AM, Rowan Collins
> >
collins@gmail.com>
> > wrote:
> >
> > > On 5 January 2018 at 10:38, Dan Ackroyd <danack@basereality.com> wrote:
> > >
> > > > On 2 January 2018 at 13:55, Peter Cowburn <petercowburn@gmail.com>
> > > wrote:
> > > > >
> > > > >
> > > > > Why is this bypassing the RFC process?
> > > >
> > > > That's a very good question.
> > > >
> > > > Although I'm pretty sure an RFC for this would pass unanimously,
> > > > stuff should have to go through voting rather than relying on
> > > > no-one shouting loudly enough.
> > > >
> > >
> > >
> > > Just as a counter-point to this, I understand that many (Westminster
> > > style?) parliaments have mechanisms to skip uncontroversial votes by
> > > first requiring a show of hands or voices, and only "dividing the
> > > house" (making everyone get up and register their formal votes) if there is
> dissent.
> > >
> > > I think Anatol's intent here is similar: if anyone says "Nay", we
> > > can proceed with an RFC and vote; but if it's already unanimous, why
> > > spend the time, when we could be moving onto other business?
> > >
> > > Regards,
> > > --
> > > Rowan Collins
> > > [IMSoP]
> > >
Hi!
> If there are no further comments or objection, I would like to merge this patch anytime soon and see to add a couple of helper functions for diff/compare.
No objection to the idea but please see my comments on
https://github.com/php/php-src/pull/2976.
--
Stas Malyshev
smalyshev@gmail.com
> -----Original Message-----
> From: Stanislav Malyshev [
mailto:smalyshev@gmail.com]
> Sent: Tuesday, January 2, 2018 8:43 PM
> To: Anatol Belski <
ab@php.net>;
internals@lists.php.net
> Cc: Niklas Keller <
me@kelunik.com>
> Subject: Re: [PHP-DEV] RE: High resolution timer function
>
> Hi!
>
> > If there are no further comments or objection, I would like to merge this patch
> anytime soon and see to add a couple of helper functions for diff/compare.
>
> No objection to the idea but please see my comments on
>
https://github.com/php/php-src/pull/2976.
>
Thanks, Stas. I'm working to address your comments now.
Regards
Anatol