Path: csiph.com!usenet.pasdenom.info!news.etla.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Dennis Lee Bieber <wlfraed@ix.netcom.com>
Subject: Re: time.monotonic() roll over
Date: Fri, 05 Dec 2014 12:31:48 -0500
Organization: IISS Elusive Unicorn
References: <54807cfd$0$2311$426a74cc@news.free.fr> <87vblr8lcw.fsf@elektro.pacujo.net> <mailman.16564.1417709156.18130.python-list@python.org> <87r3wf8jy8.fsf@elektro.pacujo.net> <mailman.16566.1417710430.18130.python-list@python.org> <87ppbzp9qq.fsf@elektro.pacujo.net> <5480fea7$0$12992$c3e8da3$5496439d@news.astraweb.com> <87d27yoc1a.fsf@elektro.pacujo.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.16630.1417800718.18130.python-list@python.org>
Lines: 49
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:82009

On Fri, 05 Dec 2014 08:17:53 +0200, Marko Rauhamaa <marko@pacujo.net>
declaimed the following:


>If a program spends long periods in an induced coma (which is becoming
>more and more common nowadays), the whole design of the program is under
>quite a bit of strain. What to do with time-based statistics collection?
>Should periodic operations catch up with the lost time by repeating in a
>tight loop for a zillion times? What to do with "impossible,"
>out-of-order event sequences?
>
	You do what the requirements for the system specify. If the
requirements don't state a behavior for this situation, the design of the
system is faulty and needs to be corrected.

	On my part, every system I've worked on with a "delay", "pause", or
"sleep" operation that takes a relative time as input ("pause" is otherwise
ambiguous -- some languages use it to put a prompt on a console and wait
for operator to resume) have always made the delay relative to the
processor time base. Suspending/blocking a task while the system is still
operating did mean that any pending delay likely expires immediately upon
the task being resumed/unblocked and put on the ready list.

	Now -- what to do in the case of the entire computer being hibernated
is a different matter; synchronizing the "tick" clock used by sleep with a
wall-clock/RTC to account for time spent in hibernation should immediately
expire pending sleeps (or, more correct, expire those that would have
expired if the system had not gone into hibernation).

	Your "time-based statistics collection"? If the time is based on
wall-clock time, and the system is put into hibernation, I'd expect sleeps
to be expired when coming out of hibernation, and one would have a gap in
the collected data time-stamps -- and no sudden looping to collect however
many "missed" intervals took place... The data would collect once, and then
set up for the next standard interval.

	If based upon processor clock tick, independent of wall-clock time, and
the processor clock does not tick during hibernation, then there are no
missed collection intervals from the view of the process. The process does
not know that the world stopped for some period of time.

	If the process needs to be regular with wall-clock time, and missed
intervals are a serious condition --- well; disable hibernation modes.


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/