This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Queue.get() can't be interrupted with Ctrl-C unless timed out
Type: behavior Stage:
Components: Library (Lib) Versions: Python 2.7
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: anacrolix, gvanrossum, piro, sirosen
Priority: normal Keywords:

Created on 2007-10-30 00:06 by piro, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 2223 merged python-dev, 2017-06-15 19:07
Messages (6)
msg56942 - (view) Author: Daniele Varrazzo (piro) * Date: 2007-10-30 00:06
This issue probably depends on #1167930

When waiting on a queue in blocking mode, in no timeout is set, ctrl-C
doesn't raise KeyboardInterrupt::

    q = Queue()
    q.get(True)
    # ctrl-c doesn't work here

If any timeout is set, ctrl-c works as expected::

    q = Queue()
    ONEYEAR = 365 * 24 * 60 * 60
    q.get(True, ONEYEAR)
    # ctrl-c works here

    Traceback (most recent call last):
    File "queuebug.py", line 6, in <module>
        q.get(True, ONEYEAR)
    File "/usr/lib/python2.5/Queue.py", line 174, in get
        self.not_empty.wait(remaining)
    File "/usr/lib/python2.5/threading.py", line 233, in wait
        _sleep(delay)
    KeyboardInterrupt
msg56945 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-10-30 00:53
This (and the other issue you mention) is because the regular acquire()
method on a basic lock cannot be interrupted.  That's unlikely to go
away, so you'll just have to live with this.  As you've discovered,
specifying a timeout solves the issue.  Since code running in threads
doesn't receive signals anyway (in Python), it would be fairly pointless
to slow down lock acquisition in order to support keyboard interrupts.
msg56950 - (view) Author: Daniele Varrazzo (piro) * Date: 2007-10-30 01:38
Because the easy workaround, we can live with the issue. Anyway, because
the workaround is not trivial to find, and because the behavior is
supposed to remain unchanged, maybe the issue should be mentioned in the
docs.

Thank you for the explanation :)
msg157536 - (view) Author: Matt Joiner (anacrolix) Date: 2012-04-05 03:29
Isn't this fixed in Python>=3.2?
msg295958 - (view) Author: Stephen Rosen (sirosen) * Date: 2017-06-13 20:41
Can a note be added to the Queue.get() documentation?

This behavior has been known to be at least potentially confusing for a decade, and there's no mention of it in the documentation.
msg295959 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2017-06-13 21:34
This issue is closed, but you can open a new issue to flag this in the docs.
History
Date User Action Args
2022-04-11 14:56:27adminsetgithub: 45701
2017-06-15 19:07:40python-devsetpull_requests: + pull_request2268
2017-06-13 21:34:36gvanrossumsetmessages: + msg295959
2017-06-13 20:41:00sirosensetnosy: + sirosen

messages: + msg295958
versions: + Python 2.7, - Python 2.5
2012-04-05 03:29:39anacrolixsetnosy: + anacrolix
messages: + msg157536
2007-10-30 01:38:35pirosetmessages: + msg56950
2007-10-30 00:53:11gvanrossumsetstatus: open -> closed
resolution: wont fix
messages: + msg56945
nosy: + gvanrossum
2007-10-30 00:06:30pirocreate