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 mikecrowe
Recipients methane, mikecrowe, vstinner, wocket
Date 2021-10-01.07:26:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1633073192.0.0.522650930472.issue41710@roundup.psfhosted.org>
In-reply-to
Content
vstinner wrote:
> 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().

That's correct. The only time that pthread_cond_clockwait is essential is if you don't know which clock you're going to need to use for the wait at the time of condition variable creation. (This is true for a generic condition variable wrapper that can be passed absolute timeouts using different clocks like the C++ std::condition_variable.)

However, sem_clockwait is the only way to wait on a semaphore using CLOCK_MONOTONIC, so it is worth using that rather than sem_timedwait if it's available. Similarly for pthread_mutex_clocklock.
History
Date User Action Args
2021-10-01 07:26:32mikecrowesetrecipients: + mikecrowe, vstinner, methane, wocket
2021-10-01 07:26:31mikecrowesetmessageid: <1633073192.0.0.522650930472.issue41710@roundup.psfhosted.org>
2021-10-01 07:26:31mikecrowelinkissue41710 messages
2021-10-01 07:26:31mikecrowecreate