[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Gregory P. Smith added the comment: As a data point confirming that: we tried backporting the much nicer non-polling condition implementation (https://github.com/python/cpython/commit/15801a1d52c25fa2a19d649ea2671080f138fca1.patch) to our Python 2.7 interpreter at work but ran into actual

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

STINNER Victor added the comment: > Is it possible to backport this patch to 2.7? No. Python 2.7 supports many implementations of threads: $ ls Python/thread_*h -1 Python/thread_atheos.h Python/thread_beos.h Python/thread_cthread.h Python/thread_foobar.h Python/thread_lwp.h Python/thread_nt.h

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Sergei Lebedev added the comment: Is it possible to backport this patch to 2.7? -- nosy: +superbobry ___ Python tracker ___

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Changes by Yuri Bochkarev baltazar...@gmail.com: -- nosy: +Yuri.Bochkarev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8844 ___ ___

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Changes by Antoine Pitrou pit...@free.fr: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8844 ___ ___

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

STINNER Victor victor.stin...@haypocalc.com added the comment: The test fails on FreeBSD 6.2 (x86 FreeBSD py3k buildbot) since r87292 = #10720. I reopen the issue. -- nosy: +haypo resolution: fixed - status: closed - open ___ Python tracker

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Antoine Pitrou pit...@free.fr added the comment: Well, since #10720 exists, while do you reopen this one? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8844 ___

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Changes by Antoine Pitrou pit...@free.fr: -- assignee: pitrou - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8844 ___ ___ Python-bugs-list

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Changes by Antoine Pitrou pit...@free.fr: -- dependencies: -Make gettimeofday available in time module ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8844 ___

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Antoine Pitrou pit...@free.fr added the comment: Committed in r87292. Thank you for doing this! -- resolution: accepted - fixed stage: commit review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Antoine Pitrou pit...@free.fr added the comment: Added a patch that adds support for recomputing the timeout, plus a test for it. Can this still make it into 3.2, or is it too disruptive at this point in the release process? No problem at this point, we're not yet in beta phase. I

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Reid Kleckner r...@mit.edu added the comment: Added a patch that adds support for recomputing the timeout, plus a test for it. Can this still make it into 3.2, or is it too disruptive at this point in the release process? -- Added file:

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Reid Kleckner r...@mit.edu added the comment: Waiting until the portability hacks for gettimeofday make it into core Python. -- dependencies: +Make gettimeofday available in time module ___ Python tracker rep...@bugs.python.org

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Antoine Pitrou pit...@free.fr added the comment: Actually, there is a problem in Lock.acquire and RLock.acquire. If a signal occurs and signal handling returns successfully, acquiring the lock will be retried without decrementing the timeout first. Therefore, we may end up waiting longer than

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Gregory P. Smith g...@krypto.org added the comment: Accepting that the timeout is not perfect in the face of signals as a caveat is fine (document the possibility) and can be improved later. -- ___ Python tracker rep...@bugs.python.org

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Reid Kleckner r...@mit.edu added the comment: Alternatively, do you think it would be better to ignore interrupts when a timeout is passed? If a timeout is passed, the lock acquire will eventually fail in a deadlock situation, and the signal will be handled in the eval loop. However, if the

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Antoine Pitrou pit...@free.fr added the comment: The latest patch looks good to me. -- assignee: - pitrou resolution: - accepted stage: - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8844

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Reid Kleckner r...@mit.edu added the comment: Here's a patch that makes Python-level lock acquisitions interruptible for py3k. There are many users of the C-level lock API, most of whom are not set up to deal with lock acquisition failure. I decided to make a new API function and leave the

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Antoine Pitrou pit...@free.fr added the comment: Oh, nice! I was wondering if I should merge PyThread_acquire_lock_timed with my new PyThread_acquire_lock_timed_intr, since PyThread_acquire_lock_timed wasn't available in 3.1. Yes, I think you should. I haven't tried the patch, but it

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Reid Kleckner r...@mit.edu added the comment: Here is a new version of a patch that updates recursive locks to have the same behavior. The pure Python RLock implementaiton should be interruptible by virtue of the base lock acquire primitive being interruptible. I've also updated the relevant

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Antoine Pitrou pit...@free.fr added the comment: The RLock version gets different semantics in your patch: it doesn't retry acquiring when a signal is caught. Is there a reason for that? By the way, your patch works fine under Windows. -- ___

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Reid Kleckner r...@mit.edu added the comment: Oops, copy/paste oversight. =/ I wrote a test to verify that it handles signals, and then retries the lock acquire. -- Added file: http://bugs.python.org/file17935/lock-interrupt.diff ___ Python

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Reid Kleckner r...@mit.edu added the comment: Also, thanks for the quick reviews! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8844 ___ ___

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Antoine Pitrou pit...@free.fr added the comment: I'm imagining (for POSIX platforms) adding some kind of check for signals when the system call returns EINTR. If the signal handler raises an exception, like an interrupt should raise a KeyboardInterrupt, we can just give a different return

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

New submission from Mike Hobbs mho...@alvenda.com: Condition.wait() without a timeout will never raise a KeyboardInterrupt: cond = threading.Condition() cond.acquire() cond.wait() *** Pressing Ctrl-C now does nothing *** If you pass a timeout to Condition.wait(), however, it does behave as

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Antoine Pitrou pit...@free.fr added the comment: In 3.2, even using a timeout doesn't make the call interruptible. The solution would be to fix the internal locking APIs so that they handle incoming signals properly, and are able to return an error status. -- nosy: +gregory.p.smith,

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Antoine Pitrou pit...@free.fr added the comment: 3.2 is interesting in that it introduces a new internal API: PyThread_acquire_lock_timed(). We can therefore change that API again before release without risking any compatibility breakage. Reid, would you want to work on this? --

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Reid Kleckner r...@mit.edu added the comment: I'd like to fix it, but I don't know if I'll be able to in time. It was something that bugged me while running the threading tests while working on Unladen. I'm imagining (for POSIX platforms) adding some kind of check for signals when the