This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: clock_getres(CLOCK_REALTIME, .) may return an outdated and too high resolution

Corinna Vinschen wrote:
On Mar 22 18:47, Christian Franke wrote:
Corinna Vinschen wrote:
clock_getres already returns the coarsest time.  Did you mean the
setting in hires_ms::resolution, by any chance?  It's using the
actual setting right now.
No. Yes.

No, clock_getres(CLOCK_REALTIME, .) returns gtod.resolution() which
calls hires_ms::resolution().

Yes, I mean this function which returns the 'actual' value from

If clock_setres() is used, this setting should be returned instead
of the 'actual' value at the time of the setting.
Well, I'm not overly concerned about clock_setres, given that it's
probably not used at all :)
Yes, it is not POSIX and does not exist on Linux, FreeBSD, ...

It IMO is useful as CLOCK_REALTIME does only provide a rather coarse
default resolution on Cygwin.
I see your point, but what bugs me a bit is the fact that
clock_getres(CLOCK_REALTIME) and clock_setres(CLOCK_REALTIME) will
always return the same value coarsest, regardless what value has been set.

If clock_setres was called and succeeded, then clock_getres(.) should return the value set before.

If clock_setres was not called, the coarsest value is IMO the only value that can be guaranteed.

The actual value returned by NtQueryTimerResolution is simply useless in this context: It is the minimum of all resolutions currently set by all running processes. It may change at any time. There is apparently no way the query the current setting of the current process.

clock_gettime is part of the POSIX realtime extensions. On Linux it requires -lrt which implies -lpthreads. So if clock_gettime is used we can probably assume that the program wants a finer resolution.

This leads to a possible alternative if clock_setres is not used: On first call of clock_gettime/getres set a finer (the finest?) resolution and return this with clock_getres.

Drawback: The finer resolution will persist until this process and all childs terminate. This may have unknown impact on performance, power management or whatever.

This could be fixed by resetting the resolution to default if clock_gettime is no longer used for some time (e.g. >= 10min).

Drawback: Even more complexity :-)

I added this comment to clock_setres at one point:

   /* Convert to 100ns to match OS resolution.  The OS uses ULONG values
      to express resolution in 100ns units, so the coarsest timer resolution
      is<  430 secs.  Actually the coarsest timer resolution is only slightly
      beyond 15ms, but this might change in future OS versions, so we play nice
      here. */

So, what if the OS really returns bigger values in coarsest at one
point?  I know, I know, that's unlikely to the point of non-existence.

- Unlike on e.g. Linux, CLOCK_REALTIME does not provide a better
resolution than gettimeofday().
We can only use what the OS provides.  Starting with Windows 8 there
will be a new function call GetSystemTimePreciseAsFileTime:

This would provide an easy solution for >= Win8: clock_gettime returns GetSystemTimePreciseAsFileTime, clock_getres returns constant 1us.


-- Problem reports: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]