>> sleep() is implemented in the kernel. The kernel is notified when a >> clock is set, and so can choose how to handle time adjustement. Most >> "sleeping" functions use the system clock but don't care of clock >> adjustement. > > We're going around in circles. I'm not asking what sleep does, I want > on principle a timer that does the same thing as sleep(), regardless > of how sleep() works. So if on some OS sleep() uses the same algorithm > as CLOCK_MONOTONIC_RAW, I want my timer to use that too. But if on > some other OS sleep() uses CLOCK_MONOTONIC, I want my timer there to > use that. And if on some OS sleep() is buggy and uses the time-of-day > clock, well, I wouldn't mind if my timer used the same thing.
sleep() takes a number of seconds as argument, so CLOCK_MONOTONIC should be used, not CLOCK_MONOTONIC_RAW. If I understood correctly, the unit of CLOCK_MONOTONIC is a second, whereas CLOCK_MONOTONIC_RAW may be faster or slower than a second. It looks like CLOCK_MONOTONIC_RAW was added to write a NTP server in user-space. Extract of the mail including the patch adding CLOCK_MONOTONIC_RAW to the Linux kernel: "In talking with Josip Loncaric, and his work on clock synchronization (see btime.sf.net), he mentioned that for really close synchronization, it is useful to have access to "hardware time", that is a notion of time that is not in any way adjusted by the clock slewing done to keep close time sync. Part of the issue is if we are using the kernel's ntp adjusted representation of time in order to measure how we should correct time, we can run into what Paul McKenney aptly described as "Painting a road using the lines we're painting as the guide". I had been thinking of a similar problem, and was trying to come up with a way to give users access to a purely hardware based time representation that avoided users having to know the underlying frequency and mask values needed to deal with the wide variety of possible underlying hardware counters." https://lkml.org/lkml/2008/3/19/260 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
