[D-runtime] Why is clock_gettime() commented out?

[Fawzi Mohamed]

On 19-nov-10, at 20:10, Jonathan M Davis wrote:

> On Friday, November 19, 2010 10:40:29 Sean Kelly wrote:
>> On Nov 18, 2010, at 9:38 PM, Jonathan M Davis wrote:
>>> On Thursday 18 November 2010 21:24:16 Sean Kelly wrote:
>>>> On Nov 18, 2010, at 6:57 PM, Jonathan M Davis wrote:
>>>>> Is there a particular reason why clock_gettime() and various  
>>>>> related
>>>>> posix C time functions are all commented out in  
>>>>> core.sys.posix.time and
>>>>> core.sys.posix.signals? They're necessary to get either a realtime
>>>>> clock or a monotonic clock on Posix systems. It is true that that
>>>>> necessetates linking with -lrt, but as far as I know, all Posix
>>>>> systems should have librt, and the flag could be added to  
>>>>> dmd.conf.
>>>>>
>>>>> The stopwatch code in std.datetime is going to be potentially
>>>>> inaccurate without clock_gettime(), and the normal time code  
>>>>> won't be
>>>>> quite as precise. Ideally, clock_gettime() would be available.  
>>>>> Why are
>>>>> all of those time functions commented out? Were they causing  
>>>>> problems
>>>>> somehow?
>>>>
>>>> I don't recall.  I wrote all of the linux header blocks while the  
>>>> others
>>>> were submitted.  My best guess is that they weren't defined back  
>>>> when I
>>>> created the headers.  I see no problem with uncommenting them so  
>>>> long as
>>>> the functions exist though.  I'll verify and then make the change  
>>>> for
>>>> linux and OSX.
>>>
>>> They definitely should exist. The caveat is that you have to link  
>>> with
>>> librt for them to work (why they didn't just stick them in glibc  
>>> proper,
>>> I have no idea - especially when anything that cares about precision
>>> time at all should be using them).
>>
>> clockid_t and related functions don't exist on OSX, so if you want  
>> to use
>> them in std.datetime you'll have to fail gracefully to something less
>> accurate.
>
> That's annoying. Well, it uses gettimeofday() if clock_gettime() isn't
> available, which isn't as good, but as is close as you can get as  
> far as I know,
> but because druntime and phobos are pre-compiled as libraries, it  
> has to be
> based on the platform (you couldn't, for instance, use  
> clock_gettime() on some
> Linux machines and gettimeofday() on others), but making MacOSX work  
> differently
> from Linux works just fine. I do have to wonder though if MacOSX has  
> its own
> functions for getting a monotonic and/or realtime clock. If so, we  
> may want to
> use those on MacOSX. It's particularly undesirable to be using a non- 
> monotonic
> clock for timing code such as std.datetime.StopWatch. But assuming  
> that my
> proposed core.time and std.datetime are accepted, it will be an  
> issue in both
> core.time and std.datetime, because while the code for getting the  
> time for
> SysTime and the like is in std.datetime, because TickDuration has to  
> go in
> core.time, the code which grabs the time from the monotonic clock is  
> in
> core.time.

see
https://github.com/fawzi/blip/blob/master/blip/time/RealtimeClock.d
I think you can lift it from there.

Fawzi
>
> - Jonathan M Davis
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime