Author shankarunni
Recipients shankarunni
Date 2014-04-18.20:12:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1397851923.06.0.0550198760464.issue21302@psf.upfronthosting.co.za>
In-reply-to
Content
I know that an earlier request to use nanosleep() has been rejected as "wontfix", but I'm filing this one for a different reason.

Today, timemodule.c:floatsleep() calls select() on platforms that support it. On Linux, select() with a timeout has an unfortunate property that it is very sensitive to clock jumps, because it computes a sleep end time based on the current kernel timestamp.

If the system clock is yanked back (by ntpd, or other processes), then the process can end up sleeping for a very long time. (E.g. if the clock is yanked back by half an hour while we are in the middle of, say, a sleep(10), then the process will sleep until "original_kernel_clock+10", which will turn into a half-hour sleep.

Yes, systems shouldn't jerk their clocks around, but we can't often control this sort of thing on end-user environments.

Using clock_nanosleep(CLOCK_MONOTONIC, 0, <timespec>, NULL) makes the sleep a much more reliable thing, and mostly insensitive to such jumps. (It'll still be affected by any adjtime(), but that's OK in this case).
History
Date User Action Args
2014-04-18 20:12:03shankarunnisetrecipients: + shankarunni
2014-04-18 20:12:03shankarunnisetmessageid: <1397851923.06.0.0550198760464.issue21302@psf.upfronthosting.co.za>
2014-04-18 20:12:03shankarunnilinkissue21302 messages
2014-04-18 20:12:02shankarunnicreate