[issue41710] Timeout is affected by jumps in system time

[Mike Crowe]

Mike Crowe  added the comment:

glibc v2.30 onwards provides sem_clockwait which can wait on either 
CLOCK_MONOTONIC or CLOCK_REALTIME. I failed to notice that 
https://sourceware.org/bugzilla/show_bug.cgi?id=14717 existed until today. :(

--
nosy: +mikecrowe

___
Python tracker 
<https://bugs.python.org/issue41710>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41710] acquire(timeout) of threading.Lock and threading.Condition is affected by jumps in system time: Python should use sem_clockwait(CLOCK_MONOTONIC)

[Mike Crowe]

Mike Crowe  added the comment:

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.

--

___
Python tracker 
<https://bugs.python.org/issue41710>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com