datetime review part 2

Jonathan M Davis jmdavisProg at gmx.com
Fri Nov 26 06:33:40 PST 2010


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.

Oh. Well that isn't the same magnitude of problem at all. I wouldn't have 
thought that that the computer going to sleep/hibernating to RAM would cause 
that sort of problem, but I guess that it could. I have no idea if Windows or 
Linux would be affected in the same way. They might be. I don't have any way to 
test it. Regardless, it's still a bit problematic, but acceptable I think. If it 
could be verified whether Linux or Windows have the same problem, that would be 
good. It probably should be put in the documentation.

It really never would have occurred to me that putting the computer to 
sleep/hibernating to RAM would affect the clock. Of course, since I don't have a 
working laptop (and I've hated having it go to sleep when I've had one), I 
certainly wouldn't run into it personally.

- Jonathan M Davis


More information about the Digitalmars-d mailing list