This is the mail archive of the cygwin@cygwin.com 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: [PATCH] gettimeofday time travels



Discussion at last! Thanks all for your input. Thoughts inline...


Christopher Faylor writes:
 > >I don't believe my patch to be dirtier than the implementation (no
 > >offence intended!). Please reconsider it.
 > 
 > Maybe mentioning the word "dirty" a few more times will get your
 > patch in.  Keep at it!

:-)

Maybe next time I'll just send the patch and not prejudge myself.


Andre Srinivasan writes:
 > Please forgive my ignorance on this, but can we leverage off that
 > fact that the xemacs use of ctime() in the impl of
 > (current-time-string) results in the correct time whereas the impl
 > of current-time results in the incorrect time after a
 > suspend/hibernation?
 > 
 > What is correct about how current-time-string uses ctime and can
 > that be generalized into gettimeofday?

(current-time-string) uses cygwin time() which uses W32
GetSystemTime(), (current-time) uses cygwin gettimeofday() which uses
W32 QueryPerformance*. The "generalization" would be to revert the
change to the gettimeofday implementation so it doesn't use
QueryPerformance*.


David Kilroy writes:
 > An alternative method would be to listen for a suspend (or resume) and
 > somehow either
 >  a) reset gtod::inited to FALSE. gtod::prime runs on next call of
 > gettimeofday
 >  b) call gtod::prime() immediately (on resume)

As David points out, this would involve a non-localised change. I
prefer my patch or...


Chris January writes:
 > On Windows NT, you can use the ZwQuerySystemInformation internal
 > call with the SystemTimeOfDayInformation structure to get the
 > current time of day at a greater resolution than you can with the
 > Performance counters. I'm not sure about the granularity though -
 > that's something that would have to be tested. However the value
 > doesn't suffer from time-travelling problems. If indeed the
 > granularity is too coarse, you could still use the value to check
 > that the QueryPerformanceCounters value is sane (which is what I
 > believe this discussion was originally about).

If ZwQuerySystemInformation is NT only, I guess its out (I have 9.6Kbs
connectivity so I can't currently check).

I like the idea of using ZwQuerySystemInformation to provide a bound
to the value returned by QueryPerformanceCounter which AFAICS could
equally be implemented using GetSystemTime, but I'm not sure that it
wins that much over my approach.


So we either
   1. Call GetSystemTime every time to verify that our
      QueryPerformanceCounter calculation is within some delta.
      Reinitialise using QueryPerformanceFrequency if not.
      [CJ approach]

or
   2. Reinitialise using QueryPerformanceFrequency at least once every
      delta. [PA approach].

Both approaches cope with suspend/resume and base time changes of more
than delta.

I the decision is now a question of efficiency. My approach is
simpler, and it means we don't have to call both
QueryPerformanceCounter and GetSystemTime every time. It also means we
don't have to do arithmetic to get the result of GetSystemTime in some
form in which it can be compared to our QueryPerformanceCounter
calculation.

I can't see any other reason to pick ChrisJ's method over mine?

Thoughts anyone...?

- Phil


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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