Message402995
| 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:32 | mikecrowe | set | recipients:
+ mikecrowe, vstinner, methane, wocket |
| 2021年10月01日 07:26:31 | mikecrowe | set | messageid: <1633073192.0.0.522650930472.issue41710@roundup.psfhosted.org> |
| 2021年10月01日 07:26:31 | mikecrowe | link | issue41710 messages |
| 2021年10月01日 07:26:31 | mikecrowe | create |
|