This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients vstinner
Date 2014-07-23.02:09:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1406081401.66.0.461602325424.issue22043@psf.upfronthosting.co.za>
In-reply-to
Content
Currently, socket methods (ex: accept, recv, recvfrom, recvmsg, send, sendto, sendmsg), threading.Lock.acquire() and threading.RLock.acquire() use the system clock to compute their timeout. It's fine for the first call. But if the call is interrupted and the timeout need to be recomputed, it can wait too short or too long. Timeouts must use a monotonic clock, not the system clock. See the PEP 418 for more information.

Python modules were already patched to use the time.monotonic() function implemented in Python 3.3.

Attached patch fixes also functions which still use the system clock to compute timeouts.

A major change of the patch is that a monotonic clock is now require to use Python 3.5. Last time I checked, there was only one OS without monotonic clock: GNU Hurd. Hurd maintainers can patch Python 3.5 to fallback on the system clock until Hurd provides a monotonic clock.

Another important change is that Python now depends on the librt on Solaris and on Linux with glibc older than 2.17 (clock_gettime is now available directly in the libc since glibc 2.17).
History
Date User Action Args
2014-07-23 02:10:03vstinnersetrecipients: + vstinner
2014-07-23 02:10:01vstinnersetmessageid: <1406081401.66.0.461602325424.issue22043@psf.upfronthosting.co.za>
2014-07-23 02:10:01vstinnerlinkissue22043 messages
2014-07-23 02:10:01vstinnercreate