This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 accuracy for precision.  Others have already pointed this
out and after a google/msdn search I am now convinced.

I think the best we can probably do is to use the multimedia timer
functions to get 1ms accuracy and I'll be redoing gettimeofday to use
those in the next couple of days.

I'm *very* sorry for making you jump through hoops.

If someone wants to step forward to convince me that I'm wrong in now
thinking that the QueryPerformance* functions are bad news, then please
feel free.

Otherwise, 1.3.11 will have YA implementation of gettimeofday.

cgf

On Sat, May 18, 2002 at 02:02:25PM +0100, Philip Aston wrote:
>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 statically.
> > 
> > What is wrong with allocating a muto statically?  You only need one for
> > this application in cygwin.
>
>The mutex is part of my generic event listener list. Whilst I allocate
>my event listener list statically, others may wish to do otherwise.
>
> > >Christopher Faylor writes:
> > > > It may make sense to just make all of the members of the hires
> > > > class static since they are just maintaining global state.
> > >
> > >Agree. Personally I'd use a singleton object rather than static
> > >members which would also allow hires to continue to be a wm_listener,
> > >but it amounts to the same thing. However, I didn't do this as I
> > >consider it outside of the scope of the fix.
> > 
> > This looks like nice work but I am still concerned about the necessity
> > of starting up the windows thread and using the windows event loop as I
> > mentioned in previous email.  I'd rather not have that overhead if it
> > can be avoided.
>
>I can't think of anyway to detect the power events other than to run
>an event loop.
>
>Note, my implementation will not start the windows thread unless a
>hires is used. Unfortunately a hires is used by the strace/printf
>methods, so its hard to avoid.
>
> > For the cygwin part, the patch is also big enough that it requires
> > an assignment. Hopefully you've looked at
> > http://cygwin.com/contrib.html by now...
>
>Yes. I have put the wheels in motion to get a disclaimer from my
>employer.
>
> > The w32api part should be posted separately to cygwin-patches so
> > that Danny will see it and apply it.
>
>Done.
>
>
>- 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/

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]