Why doesn't mktspec() use clock_gettime?

[Jonathan M Davis via Digitalmars-d]

On Friday, January 09, 2015 18:03:15 Andrei Alexandrescu via Digitalmars-d wrote:
> cc Sean Kelly
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/core/sync/config.d#L28
>
> Looks like that use has been disable with static if (false). What was
> the reason?
>
> A coworker spent a few hours debugging a matter that pointed to this
> issue. He removed the "false" and replaced CLOCK_REALTIME with
> CLOCK_MONOTONIC in our druntime tree.
>
> Any insight into the matter? How should we address it by supporting
> multiple clock types portably?

It's probably because Mac OS X doesn't have clock_gettime, even though it's
POSIX. std.datetime.Clock.currTime currently uses gettimeofday for getting
the wall clock time on OS X (and clock_gettime on the other POSIX systems), which I'm not a fan of, but AFAIK, it works.
However, I probably should try at some point to find a more precise wall
clock function than gettimeofday for Mac OS X.

For when the monotonic clock is needed though, gettimeofday really doesn't
cut it, because it's not monotonic. And for that, you need mach_absolute on
Mac OS X, and clock_gettime with CLOCK_MONOTONIC on the other POSIX systems.
You can look at core.time.MonoTime.currTime for that:

https://github.com/D-Programming-Language/druntime/blob/master/src/core/time.d#L1848

though it's obviously not looking to fill a timespec. However, I would point
out that sem_timedwait (used in core.sync.semaphore) expects a timespec
which represents a duration from January 1st, 1970 at midnight, not the
monotonic time, so CLOCK_REALTIME or gettimeofday is required in that case
rather than CLOCK_MONOTONIC, and using CLOCK_MONOTONIC would likely make it
misbehave rather badly. I don't know about pthread_cond_timedwait though
(which is the other place that mktspec is used in druntime outside of
core.sync.config). As far as I can tell, its man page utterly fails to make
it clear what it expects for its abstime argument. It makes it sound like
it's at least sometimes possible to select which clock to use, but I don't
know how, and it doesn't say what the default is. So either CLOCK_REALTIME
or CLOCK_MONOTONIC could be the correct solution depending on what it
requires. However, the C++ code that I've used in the past to interact with
pthread_cond_timedwait seems to use the monotonic clock, so that's probably
what it expects. Certainly, I think that it would be the correct choice from
an implementation perspective, since it can't possibly use the wall clock
time internally for something like that and not have bugs, and forcing a
conversion from wall clock time internally like sem_timedwait's API would
just adds one more place where the system clock could be shifted and screw
up the result.

Regardless, simply having mktspec use either the monotonic clock or the wall
clock is probably wrong, and we probably need to either get rid of mktspec
in favor of separate functions for the different types of time or change it
so that you can choose whether you want the monotonic clock or the wall
clock. In either case, the reason that it doesn't use clock_gettime is
almost certainly because it doesn't exist on Mac OS X.

- Jonathan M Davis