Message315811
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. |
|
Date |
User |
Action |
Args |
2018-04-26 19:04:40 | pdgoins-work | set | recipients:
+ pdgoins-work, tim.peters, paul.moore, pitrou, vstinner, tim.golden, neologix, zach.ware, steve.dower, tupl |
2018-04-26 19:04:40 | pdgoins-work | set | messageid: <1524769480.25.0.682650639539.issue21822@psf.upfronthosting.co.za> |
2018-04-26 19:04:40 | pdgoins-work | link | issue21822 messages |
2018-04-26 19:04:40 | pdgoins-work | create | |
|