RE: Missed patch? (gettimeofday time travels V2)

2003-01-14 Thread Fish
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Faylor wrote: > On Mon, Jan 13, 2003 at 09:55:15PM -0800, Fish wrote: > > > >Is there any reason why Philip Aston's 6 Jul 2002 patch to > >gettimeofday et. al. logic to correct for WM_POWERBROADCAST events > >(PBT_APMRESUMESUSPEND, PBT_

Re: Missed patch? (gettimeofday time travels V2)

2003-01-14 Thread Christopher Faylor
On Mon, Jan 13, 2003 at 09:55:15PM -0800, Fish wrote: > >Is there any reason why Philip Aston's 6 Jul 2002 patch to >gettimeofday et. al. logic to correct for WM_POWERBROADCAST events >(PBT_APMRESUMESUSPEND, PBT_APMRESUMEAUTOMATIC, PBT_APMRESUMECRITICAL) >hasn't made it into the sources yet? > >ht

Missed patch? (gettimeofday time travels V2)

2003-01-13 Thread Fish
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there any reason why Philip Aston's 6 Jul 2002 patch to gettimeofday et. al. logic to correct for WM_POWERBROADCAST events (PBT_APMRESUMESUSPEND, PBT_APMRESUMEAUTOMATIC, PBT_APMRESUMECRITICAL) hasn't made it into the sources yet? http://sources.r

Re: [PATCH] gettimeofday time travels V2

2002-05-20 Thread Christopher Faylor
I hate to say this, but after reading various references on the QueryPerformance* functions, I don't think that we should be using them. There was a clamor to implement things this way a few months ago, and I implemented this to provide improved precision. However, it looks like I sacrificed acc

Re: [PATCH] gettimeofday time travels V2

2002-05-18 Thread Philip Aston
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 mutos since mutos must be allocated

Re: [PATCH] gettimeofday time travels V2

2002-05-17 Thread Christopher Faylor
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 mutos since mutos must be allocated statically. What is wrong with allocat

Re: [PATCH] gettimeofday time travels V2

2002-05-15 Thread Philip Aston
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

[PATCH] gettimeofday time travels V2

2002-05-15 Thread Philip Aston
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 in winsup/w32api/

Re: [PATCH] gettimeofday time travels

2002-05-13 Thread Christopher Faylor
On Mon, May 13, 2002 at 09:56:58AM +0100, Philip Aston wrote: > >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. > >S

RE: [PATCH] gettimeofday time travels

2002-05-13 Thread Robert Collins
> -Original Message- > From: Philip Aston [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 13, 2002 6:57 PM > To: [EMAIL PROTECTED] > Subject: Re: [PATCH] gettimeofday time travels > > > > Philip Aston writes: > > Christopher Faylor writes: > &g

Re: [PATCH] gettimeofday time travels

2002-05-13 Thread Philip Aston
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 values, which I'll track down, I now have

Re: [PATCH] gettimeofday time travels

2002-05-10 Thread Philip Aston
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

2002-04-16 Thread Philip Aston
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

2002-04-16 Thread Robert Collins
> -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 > > > > cgf writes: > > On Mon, Apr 15, 2002 at 09:58:48PM +010

Re: [PATCH] gettimeofday time travels

2002-04-16 Thread Philip Aston
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. Understoo

Re: [PATCH] gettimeofday time travels

2002-04-15 Thread Christopher Faylor
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. cgf -- Unsubscribe info: http://c

[PATCH] gettimeofday time travels

2002-04-15 Thread Philip Aston
(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 suspend bug