Re: [PATCH] gettimeofday time travels V2

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

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

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

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 info: http://cyg

Re: [PATCH] gettimeofday time travels

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

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

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

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

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

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

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

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