> Where in the stdlib do we actually calculate timeouts instead of using > the timeouts built into the OS (e.g. select())?
At least in threading and queue modules. The common use case is to retry a function with a timeout if the syscall was interrupted by a signal (EINTR error). The socket module and _threading.Lock.acquire() implement such retry loop using the system clock. They should use a monotonic clock instead. > I think it would be nice if we could somehow use the *same* clock as > the OS uses to implement timeouts. On Linux, nanosleep() uses CLOCK_MONOTONIC whereas POSIX suggests CLOCK_REALTIME. Some functions allow to choose the clock, like pthread locks or clock_nanosleep(). > I'd be happier if the fallback function didn't try to guarantee things > the underlying clock can't guarantee. I.e. I like the idea of having a > function that uses some accurate OS clock if one exists but falls back > to time.time() if not; I don't like the idea of that new function > trying to interpret the value of time.time() in any way. We may workaround some OS known bugs like: http://support.microsoft.com/?id=274323 The link contains an example how to workaround the bug. The idea of the workaround is to use two different monotonic clocks to detect leaps, with one trusted clock (GetTickCount) and one untrusted clock having an higher resolution (QueryPerformanceCounter). I don't think that the same algorithm is applicable on other OSes because other OSes usually only provide one monotonic clock, sometimes though different API. Victor _______________________________________________ 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
