gettime time travels after suspend

I have a running process which prints out the result of gettimeofday() at regular intervals. If I suspend and resume my machine then the value returned by gettimeofday() is incorrect - it jumps several days into the future. Doing the same with time() is fine. I don't want to point fingers, but

Re: gettime time travels after suspend

How about the attached quick and dirty fix? - Phil 2002-04-14 Philip Aston <[EMAIL PROTECTED]> * times.cc (hires::usecs): Sync counter every ten minutes to work around suspend bug. Index: cygwin/ti

Re: gettime time travels after suspend

I wrote: > Date: Thu, 18 Apr 2002 05:16:54 +0100 > To: cygwin at cygwin dot com > Subject: Re: gettime time travels after suspend > > How about the attached quick and dirty fix? As you can see, I haven't installed this patch locally yet :-) - Phil -- Unsubscribe info: http://cygwin

[PATCH] gettimeofday time travels

(Resent with appropriate subject in case the original was missed in the discussion thread). How about the attached quick and dirty fix? - Phil 2002-04-14 Philip Aston <[EMAIL PROTECTED]> * times.cc (hires::usecs): Sync counter every ten minutes to work around s

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 ot

RE: [PATCH] gettimeofday time travels

Robert Collins writes: > > -Original Message- > > From: Philip Aston [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 16, 2002 6:30 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [PATCH] gettimeofday time travels > > > > &g

Re: [PATCH] gettimeofday time travels

Christopher Faylor writes: > An NT only solution is not a solution. I wasn't for a moment suggesting that it was. > Syncing every "x" seconds also is not a solution. > > The correct solution is to resync after events which cause the clock to > stop. OK, I'll have a crack at this over the

Re: [PATCH] gettimeofday time travels

Philip Aston writes: > Christopher Faylor writes: > > The correct solution is to resync after events which cause the > > clock to stop. > > OK, I'll have a crack at this over the weekend following David's > hints. Short of some unexpected wParam va

[PATCH] gettimeofday time travels V2

Patch and changelog below, two new files attached (sorry couldn't figure out -N for cvs diff). Chat for the interested: Philip Aston writes: > Short of some unexpected wParam values, which I'll track down, I > now have this working. This turned out to be an incorrect value

Re: [PATCH] gettimeofday time travels V2

Philip Aston writes: * From: "Philip Aston" * To: cygwin at cygwin dot com * Date: Sat, 6 Jul 2002 11:55:17 +0100 * Subject: [PATCH] gettimeofday time travels V2 Hmm... ironically my mailer wasn't running against the patched DLL :-) - Phil -- Unsubscribe

Re: [PATCH] gettimeofday time travels V2

Christopher Faylor writes: > On Sat, Jul 06, 2002 at 11:55:17AM +0100, Philip Aston wrote: > >The list in thread.h is specific to a type, and intrusive. I used a > >mutex to create my own thread-safe, non-intrusive list. I used pthread > >mutexes instead of muto

touch caused BSOD!

I've recently upgraded to W2K. Wanting to use inet-utils I ran iu-config, and was somewhat shocked to get the blue screen of death. I investigated this further. The BSOD occurred if I touch a file in /etc: $ touch /etc/abc or $ > /etc/abc Touching files outside of /etc doesn't

Re: touch caused BSOD!

Charles Wilson writes: > Go to "My Computer"->Properties->"Advanced Tab"->"Startup and Recovery" > > Then, in the "Write debugging information" chooser, pick "Small Memory > Dump (64k)". Make a note of the filenmae to which the memory dump will > be saved. Then Exit. > > Now, make yo