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: <15547.57598.310101.639521@bea.com>
Date: Tue, 16 Apr 2002 09:29:50 +0100
To: cygwin AT cygwin DOT com
Subject: Re: [PATCH] gettimeofday time travels 


cgf writes:
 > On Mon, Apr 15, 2002 at 09:58:48PM +0100, Philip Aston wrote:
 > >How about the attached quick and dirty fix?
 > 
 > I'm sorry but I don't think a quick and dirty fix is justified if
 > there are other alternatives. I haven't seen any other alternatives
 > discussed yet.

Understood and appreciated. Here's some justificiation/discussion for
my fix.

I'm no W32 expert but:

1. Suspend and resume changes the counters in a seemingly
   unpredictable way. (I'd have guessed that the counters would have
   been "suspended" and hence the reported time after a suspend would
   be in the past). I wouldn't want to patch into suspend notification
   API's to implement this.

2. There are other situations in which the base time could
   be invalidated (NTP update, timezone change, user clock change).
   How can/should we detect and react to these events?

3. There is a chance that QueryPerformance* _should_ take
   suspend/resume into account and that my hardware is at fault. Any
   volunteers to run my test case on their machines?

- 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/