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?

- Jonathan M Davis

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.

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

- Jonathan M Davis

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.

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.

- Jonathan M Davis

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