Message 402987 - Python tracker

➜

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.

In-reply-to
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>

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

homepage