Paul Goins <paul.d.go...@intel.com> added the comment:
Not sure if I'll do the full fix (need to check w/ my employer), but I'm doing
some investigation. Here's what I know so far:
At the Python level, the KeyboardInterrupt is being raised within
_wait_for_tstate_lock, on "elif lock.acquire(block, timeout)".
Going into the C code, it looks like this goes through
lock_PyThread_acquire_lock -> acquire_timed -> PyThread_acquire_lock_timed.
acquire_timed . lock_PyThread_acquire_lock will abort the lock if it receives
PY_LOCK_INTR from acquire_timed.
My best guess right now is that PyThread_acquire_lock_timed never returns
PY_LOCK_INTR. Indeed, I see this comment at the top of the NT version of that
function:
/* Fow now, intr_flag does nothing on Windows, and lock acquires are
* uninterruptible. */
And indeed, the thread_pthread.h implementations both have a path for returning
PY_LOCK_INTR, while the thread_nt.h version does not.
...And that's where I am thus far.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue21822>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
