Two points to make here:
1. CLOCK_UPTIME_RAW exactly matches the previous behaviour, so even if it's
wrong, it's not a regression. See the next sentence from the one Eric quoted:
CLOCK_UPTIME_RAW clock that increments monotonically, in the same manner
as
CLOCK_MONOTONIC_RAW, but that does not increment while
the
system is asleep. The returned value is identical to
the
result of mach_absolute_time() after the appropriate
mach_timebase conversion is applied.
The previous implementation used mach_absolute_time() with "the appropriate
mach_timebase conversion". Using CLOCK_UPTIME_RAW is maintaining the status
quo.
Moreover, libc++ is currently incorrectly/accidentally/incidentally using
CLOCK_MONOTONIC, which has frequency and time adjustments, and is definitely
un-steady. I think this patch should be committed promptly to maintain the
status quo and match what's shipping (and has shipped for 5 years) on Darwin.
Then we can argue about whether to change how steady_clock works going forward
(maybe we should).
2. I find your argument unconvincing. Why must the clock continue to increment
when the system is asleep? The text only says that it advances relative to
real time, not that it advances when the system isn't running.
> On 2016-Dec-09, at 09:15, Eric Fiselier via Phabricator
> <[email protected]> wrote:
>
> EricWF added a comment.
>
> `CLOCK_MONOTONIC_RAW` however seems to meet the requirements..
>
>
> https://reviews.llvm.org/D27429
>
>
>
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
