Message 402987 - Python tracker

Message402987

Author	vstinner
Recipients	methane, mikecrowe, vstinner, wocket
Date	2021-09-30.21:20:06
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1633036806.74.0.27539451366.issue41710@roundup.psfhosted.org>
In-reply-to

Content
On Unix, PyCOND_TIMEDWAIT() is implemented with pthread_cond_timedwait(). If pthread_condattr_setclock() is available, it uses CLOCK_MONOTONIC. Otherwise, it uses CLOCK_REALTIME. The glibc 2.30 adds pthread_cond_clockwait() which could be used to use CLOCK_MONOTONIC. But if pthread_cond_clockwait() is available (glibc 2.30 or newer), it expects that pthread_condattr_setclock() is also available. So I'm not sure that it's worth it to change PyCOND_TIMEDWAIT(). See the _PyThread_cond_after() function which computes an absolute timestamp (timespec) from a relative timeout in microseconds.

Content

On Unix, PyCOND_TIMEDWAIT() is implemented with pthread_cond_timedwait(). If pthread_condattr_setclock() is available, it uses CLOCK_MONOTONIC. Otherwise, it uses CLOCK_REALTIME.

The glibc 2.30 adds pthread_cond_clockwait() which could be used to use CLOCK_MONOTONIC. But if pthread_cond_clockwait() is available (glibc 2.30 or newer), it expects that pthread_condattr_setclock() is also available. So I'm not sure that it's worth it to change PyCOND_TIMEDWAIT().

See the _PyThread_cond_after() function which computes an absolute timestamp (timespec) from a relative timeout in microseconds.

History
Date	User	Action	Args
2021-09-30 21:20:07	vstinner	set	recipients: + vstinner, methane, wocket, mikecrowe
2021-09-30 21:20:06	vstinner	set	messageid: <1633036806.74.0.27539451366.issue41710@roundup.psfhosted.org>
2021-09-30 21:20:06	vstinner	link	issue41710 messages
2021-09-30 21:20:06	vstinner	create