This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: thoughts on timestamp problems
- From: Brian Ford <Brian dot Ford at FlightSafety dot com>
- To: cygwin-developers at cygwin dot com
- Date: Fri, 16 Oct 2009 10:36:03 -0500
- Subject: Re: thoughts on timestamp problems
- References: <4AD87152.90400@byu.net>
- Reply-to: cygwin-developers at cygwin dot com
On Fri, 16 Oct 2009, Eric Blake wrote:
> Then there was this web page:
> http://www.geisswerks.com/ryan/FAQS/timing.html
> which suggests a way to use a mixture of timeGetTime and
> QueryPerformanceCounter to get sub-millesecond sleep accuracy without the
> penalty of calling timeBeginPeriod (in other words, use normal millisecond
> granularity to burn most of the time down, then QueryPerformanceCounter to
> get the rest of the way without burning processor time for the bulk of the
> sleep).
I would strongly discourage a "high resolution sleep" in Cygwin using this
method. If a particular application deems it necessary, they can always
do this. But, a 1 - 15 ms CPU burn to provide high resolution "sleeps" is
not something an OS or OS emulation layer should be doing. To me,
timeBeginPeriod is a way better solution because it doesn't cause CPU burn
(Yes, I know it increases interrupt tick processing overhead). Don't ever
emulate sleep with burn in a library without fully exposing this to the
developer please. The future is a multi-threaded multi-tasking world
where resources should NOT be wasted like this unless absolutely required.
--
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...