Paul Goins <paul.d.go...@intel.com> added the comment: Okay, I think I need to abandon my research into this. This does seem to have quite an amount of complexity to it and is probably more than I should be taking on at this point in time.
Anyone else who wants to look at this, consider it fair game. Parting thoughts based on my limited expertise in the area, take them or ignore them: * Semaphore-based AllocNonRecursiveMutex (!_PY_USE_CV_LOCKS): Using WaitForSingleObjectEx with alertable set to TRUE may be one path forward, however it seems like that would involve tracking all threads performing a ctrl-c-interruptible wait and calling QueueUserAPC with a no-op callback for each such thread to cause the wait to terminate early. I don't particularly like the need to roll-our-own tracking, but at least off-hand and based on my somewhat limited experience in this area, I don't know of a better way. Hopefully someone else does. * CriticalSection/Semaphore-based AllocNonRecursiveMutex (_PY_USE_CV_LOCKS with _PY_EMULATED_WIN_CV): I don't know of a way of interrupting the CriticalSection lock, but the WaitForSingleObjectEx strategy may be usable on the semaphore-based condition variable. * SRWLock/ConditionVariable-based AllocNonRecursiveMutex (_PY_USE_CV_LOCKS with !_PY_EMULATED_WIN_CV): Similarly, I don't know of a way to interrupt the SRWLock. However, similar to WaitForSingleObjectEx, it may be possible to wake the condition variables via a Ctrl-C if we add our own tracking for such. I'm not sure if this gets us quite to where we need to be or not. Hopefully the above notes are of some value. ---------- _______________________________________ 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
