datetime review part 2

[Jonathan M Davis]

On Friday 26 November 2010 06:14:29 Michel Fortin wrote:
> On 2010-11-26 08:59:58 -0500, Jonathan M Davis <jmdavisProg at gmx.com> said:
> > On Friday 26 November 2010 04:38:47 Michel Fortin wrote:
> >> One thing I wonder about... what is the expected behaviour if you put
> >> the computer to sleep in the middle of the above program? With
> >> mach_absolute_time, the clock stops counting while the computer is put
> >> to sleep. Does TickDuration.currSystemTick works like that on all
> >> systems? If there's a difference in behaviour perhaps it should be
> >> documented.
> > 
> > Really? That is... not good. Unacceptable in fact. Even if it were
> > acceptable when dealing with stop watch and benchmarking code (which is
> > questionable), it totally fries Clock.currAppTick(), which tells you how
> > long the application has been running. The documentation for
> > QueryPermanceCounter() and clock_gettime() give no indication that the
> > clock stops counting when a thread is sleeping.
> 
> No no no... not when a *thread* is sleeping. When the *computer* is
> sleeping; when the OS is suspended while you close the lid on a laptop
> for instance. So I start my program, it enters the sleep() function, I
> close the lid, and one minute later I reopen it and when the sleep()
> function returns the tick duration is as if the clock was stopped while
> the lid was closed, despite that the real elapsed time was far much.
> Closing the lid puts the *computer* to sleep and stops the clock, not
> the sleap() function.
> 
> I understand my example using the sleep() function was misleading
> because the term sleep had two meanings.

By the way, did you run the full unit tests on Mac OS X, or did you just test 
and fix the Mac-specific changes that I made? I assume that the unit tests pass on 
Mac OS X, but I don't know.

- Jonathan M Davis