digitalmars.D - Why doesn't mktspec() use clock_gettime?
- Andrei Alexandrescu (11/11) Jan 09 2015 cc Sean Kelly
- weaselcat (3/14) Jan 09 2015 https://github.com/D-Programming-Language/druntime/commit/998739c
- Andrei Alexandrescu (3/24) Jan 09 2015 Thanks. What library would that be? Is it unavailable on some platforms?...
- weaselcat (3/33) Jan 09 2015 I believe it's a POSIX system function, requires librt.
- ketmar via Digitalmars-d (8/34) Jan 09 2015 On Fri, 09 Jan 2015 19:17:49 -0800
- Mike Wey (4/36) Jan 10 2015 And on Linux we already link with librt anyway.
- Jonathan M Davis via Digitalmars-d (38/47) Jan 11 2015 It's probably because Mac OS X doesn't have clock_gettime, even though i...
- Jacob Carlborg (14/19) Jan 12 2015 I don't know if this is what you're looking for but I found these two
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
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, Andreihttps://github.com/D-Programming-Language/druntime/commit/998739c
Jan 09 2015
On 1/9/15 6:13 PM, weaselcat wrote:On Saturday, 10 January 2015 at 02:03:17 UTC, Andrei Alexandrescu wrote:Thanks. What library would that be? Is it unavailable on some platforms? If always available, couldn't we just link with it? -- Andreicc 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, Andreihttps://github.com/D-Programming-Language/druntime/commit/998739c
Jan 09 2015
On Saturday, 10 January 2015 at 03:17:50 UTC, Andrei Alexandrescu wrote:On 1/9/15 6:13 PM, weaselcat wrote:I believe it's a POSIX system function, requires librt.On Saturday, 10 January 2015 at 02:03:17 UTC, Andrei Alexandrescu wrote:Thanks. What library would that be? Is it unavailable on some platforms? If always available, couldn't we just link with it? -- Andreicc 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, Andreihttps://github.com/D-Programming-Language/druntime/commit/998739c
Jan 09 2015
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:e/sync/config.d#L28On 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==20=20 Thanks. What library would that be? Is it unavailable on some platforms?=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, Andreihttps://github.com/D-Programming-Language/druntime/commit/998739cIf always available, couldn't we just link with it? -- Andreion 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
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:And on Linux we already link with librt anyway. -- Mike WeyOn 1/9/15 6:13 PM, weaselcat wrote: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 Saturday, 10 January 2015 at 02:03:17 UTC, Andrei Alexandrescu wrote:Thanks. What library would that be? Is it unavailable on some platforms? If always available, couldn't we just link with it? -- Andreicc 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, Andreihttps://github.com/D-Programming-Language/druntime/commit/998739c
Jan 10 2015
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
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] -- /Jacob Carlborg
Jan 12 2015