Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: "Philip Aston" <paston AT bea DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15578.30482.568575.767214@bea.com>
Date: Thu, 9 May 2002 14:18:10 +0100
To: cygwin AT cygwin DOT com
Subject: Re: [PATCH] gettimeofday time travels
In-Reply-To: <20020508144104.GA1093@redhat.com>
References: <15547 DOT 16136 DOT 163472 DOT 840007 AT bea DOT com>
	<20020415214133 DOT GA19612 AT redhat DOT com>
	<15577 DOT 12319 DOT 622365 DOT 566799 AT bea DOT com>
	<20020508144104 DOT GA1093 AT redhat DOT com>


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/