www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why doesn't mktspec() use clock_gettime?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 09 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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
Jan 09 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 09 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
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.
Jan 09 2015
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
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/cor=
e/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
=20 Thanks. What library would that be? Is it unavailable on some platforms?=
=20
 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...
Jan 09 2015
parent Mike Wey <mike-wey example.com> writes:
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
Jan 10 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Jan 11 2015
parent Jacob Carlborg <doob me.com> writes:
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
Jan 12 2015