Xavier de Gaye added the comment:
Got now a full fledged gdb. Thread #1 loops infinitely in the "while
(_Py_atomic_load_relaxed(&gil_locked))" loop in take_gil(). Thread #2 is stuck
in the MUTEX_LOCK(gil_mutex) statement in drop_gil() as can be seen by setting
a breakpoint at the following line and seeing that this breakpoint is never hit.
Setting gil_interval to 10 (from the initial value of 1) from gdb, allows the
test to pass.
With this patch of PyCOND_TIMEDWAIT():
diff -r eee959fee5f5 Python/condvar.h
--- a/Python/condvar.h Sat May 07 21:13:50 2016 +0300
+++ b/Python/condvar.h Mon May 16 15:52:49 2016 +0200
@@ -99,6 +99,7 @@
PyCOND_ADD_MICROSECONDS(deadline, us);
ts.tv_sec = deadline.tv_sec;
ts.tv_nsec = deadline.tv_usec * 1000;
+ PyCOND_GETTIMEOFDAY(&deadline);
and a breakpoint set on pthread_cond_timedwait(). When this breakpoint is hit,
there is 20 usec elapsed time instead of the value of 1 (as requested by 'us')
between ts and deadline as shown here:
(gdb) p ts
$1 = {tv_sec = 1463407197, tv_nsec = 468546000}
(gdb) p deadline
$2 = {tv_sec = 1463407197, tv_usec = 468566}
And when iterating the loop, the measured elapsed times are: 20, 12, 12, 11,
11, 11.
Clearly, the ts date is in the past when pthread_cond_timedwait() is called,
and the function returns immediately without releasing the mutex. This is the
expected behavior[1].
[1] http://linux.die.net/man/3/pthread_cond_wait
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26939>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
