On 07Apr2012 18:49, Guido van Rossum <gu...@python.org> wrote: | On Sat, Apr 7, 2012 at 6:26 PM, Raymond Hettinger | <raymond.hettin...@gmail.com> wrote: | > Just to clarify my previous post. | > It seems clear that benchmarking and timeout logic would benefit | > from a clock that cannot be adjusted by NTP.
Indeed. Except for calendar programs setting alarms:-) I suppose they wake up regularly and consult local time anyway. | > I'm unclear on whether time.sleep() will be based on the same clock | > so that timeouts and sleeps are on the same basis. | | I made the same suggestion earlier but I don't know that anyone did | anything with it. :-( It would be nice to know what clock sleep() uses | on each of the major platforms. I saw it but didn't know what I could do with it, or even if it can be found out in any very general sense. Looking at nanosleep(2) on a recent Linux system says: POSIX.1 specifies that nanosleep() should measure time against the CLOCK_REALTIME clock. However, Linux measures the time using the CLOCK_MONOTONIC clock. This probably does not matter, since the POSIX.1 specification for clock_settime(2) says that discontinuous changes in CLOCK_REALTIME should not affect nanosleep(): Setting the value of the CLOCK_REALTIME clock via clock_settime(2) shall have no effect on threads that are blocked waiting for a relative time service based upon this clock, including the nanosleep() function; ... Consequently, these time services shall expire when the requested relative interval elapses, independently of the new or old value of the clock. and POSIX's nanosleep(3p) says: ... except for the case of being interrupted by a signal, the suspension time shall not be less than the time specified by rqtp, as measured by the system clock CLOCK_REALTIME. | > For scheduling logic (such as the sched module), I would think that | > NTP adjusted time would be what you want. | | In my view, it depends on whether you are scheduling far in the future | (presumably guided by a calendar) or a short time ahead (milliseconds | to hours). In my view it depends on whether you're working in a calendar or in elapsed time. The scheduling range ("far in the future" for example) shouldn't be relevant, for all that "far in the future" is usually done with a calendar instead of a relative timespans in flat seconds. Raymond: | > I'm also unclear on the interactions between components implemented with | > different clocks (for example, if my logs show three seconds between | > events and a 10-second time-out exception occurs, is that confusing)? I don't think it is confusing given some more context; to me it would usually be a Big Clue that the internal supposedly-wallclock got a big adjustment between log timestamps. If that shouldn't happen it may be confusing or surprising... Cheers, -- Cameron Simpson <c...@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ The street finds its own uses for things. - William Gibson _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com