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?


Thanks,

Andrei

On Saturday, 10 January 2015 at 02:03:17 UTC, Andrei Alexandrescu 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?
>
>
> Thanks,
>
> Andrei

https://github.com/D-Programming-Language/druntime/commit/998739c

On 1/9/15 6:13 PM, weaselcat wrote:
> On Saturday, 10 January 2015 at 02:03:17 UTC, Andrei Alexandrescu 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?
>>
>>
>> Thanks,
>>
>> Andrei
>
> https://github.com/D-Programming-Language/druntime/commit/998739c

Thanks. What library would that be? Is it unavailable on some platforms? If always available, couldn't we just link with it? -- Andrei

On Saturday, 10 January 2015 at 03:17:50 UTC, Andrei Alexandrescu wrote:
> On 1/9/15 6:13 PM, weaselcat wrote:
>> On Saturday, 10 January 2015 at 02:03:17 UTC, Andrei Alexandrescu 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?
>>>
>>>
>>> Thanks,
>>>
>>> Andrei
>>
>> https://github.com/D-Programming-Language/druntime/commit/998739c
>
> Thanks. What library would that be? Is it unavailable on some platforms? If always available, couldn't we just link with it? -- Andrei

I believe it's a POSIX system function, requires librt.

On Fri, 09 Jan 2015 19:17:49 -0800
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> On 1/9/15 6:13 PM, weaselcat wrote:
> > On Saturday, 10 January 2015 at 02:03:17 UTC, Andrei Alexandrescu 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?
> >>
> >>
> >> Thanks,
> >>
> >> Andrei
> >
> > https://github.com/D-Programming-Language/druntime/commit/998739c
> 
> Thanks. What library would that be? Is it unavailable on some platforms? If always available, couldn't we just link with it? -- Andrei
on older GNU/Linux systems it requires -lrt. it doesn't with relatively new glibc (something that is 1.5 year old is ok, AFAIR), and i see no reasons to be conservative here, but...

On 01/10/2015 08:16 AM, ketmar via Digitalmars-d wrote:
> On Fri, 09 Jan 2015 19:17:49 -0800
> Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
> wrote:
>
>> On 1/9/15 6:13 PM, weaselcat wrote:
>>> On Saturday, 10 January 2015 at 02:03:17 UTC, Andrei Alexandrescu 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?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Andrei
>>>
>>> https://github.com/D-Programming-Language/druntime/commit/998739c
>>
>> Thanks. What library would that be? Is it unavailable on some platforms?
>> If always available, couldn't we just link with it? -- Andrei
> on older GNU/Linux systems it requires -lrt. it doesn't with relatively
> new glibc (something that is 1.5 year old is ok, AFAIR), and i see no
> reasons to be conservative here, but...
>

And on Linux we already link with librt anyway.

-- 
Mike Wey

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

On 2015-01-12 02:19, Jonathan M Davis via Digitalmars-d wrote:

> 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.

I don't know if this is what you're looking for but I found these two [1], [2]. I don't know if they're monotonic or not.

I also found this stackoverflow post [3] saying that mach_absolute_time and clock_get_time pauses when sleeping on iOS. Don't know if that's a problem or not. There seems to be a workaround in the post as well.

[1] https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/services/services.html

[2] http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/osfmk/man/clock_get_time.html

[3] http://stackoverflow.com/questions/12488481/getting-ios-system-uptime-that-doesnt-pause-when-asleep/12490414#12490414

-- 
/Jacob Carlborg