Repository navigation
Queue shutdown #96471
Description
Add a shutdown method to queue class (threading queue, multiprocessing, asyncio) which causes all future puts to raise (a queue.QueueShutdown) and all future gets once the queue is empty to also raise, unblocking all waiters. An optional argument immediate=True will skip the requirement for the queue to be empty.
This will enable producers and consumers to use the queue to know when to stop. This is important because both producers and consumers can be blocked waiting on the queue.
Previous discussion:
Linked PRs
- gh-96471: Add queue shutdown #96474
- gh-96471: Add queue shutdown, next step. #102499
- gh-96471: Add threading queue shutdown #104225
- gh-96471: Add asyncio queue shutdown #104228
- gh-96471: Add multiprocessing queue shutdown #104230
- gh-96471: Add threading queue shutdown #104750
- Revert "gh-96471: Add shutdown() method to queue.Queue (#104750)" #115265
- gh-96471: Correct docs for queue shutdown raises #115838
- gh-96471: Add ShutDown to threading module '__all__' #116699
- gh-96471: Correct documentation for asyncio queue shutdown #117621
- gh-96471: Add multiprocessing.Queue.shutdown() #138828
Activity
gh-96471: Correct docs for queue shutdown (#115838)
pythongh-96471: Correct docs for queue shutdown (python#115838)
gh-96471: Add ShutDown to queue.py '__all__' (#116699)
pythongh-96471: Add ShutDown to queue.py '__all__' (python#116699)
pythongh-96471: Add ShutDown to queue.py '__all__' (python#116699)
EpicWink commentedon Mar 28, 2024
@ericsnowcurrently I'm not familiar with subinterpreters. Is the subinterpreter queue compatible with this new API?
ericsnowcurrently commentedon Mar 28, 2024
Yeah, add shutdown to interpreter queues shouldn't be a problem. Basically,
Queue.shutdown()would result in setting a flag on the runtime-global queue data, which would then be reflected by calls toQueue.put()andQueue.get().gh-96471: Add asyncio queue shutdown (#104228)
gh-96471: Correct documentation for asyncio queue shutdown (#117621)
pythongh-96471: Correct docs for queue shutdown (python#115838)
pythongh-96471: Add ShutDown to queue.py '__all__' (python#116699)
pythongh-96471: Add asyncio queue shutdown (python#104228)
pythongh-96471: Correct documentation for asyncio queue shutdown (pyt…
pythongh-96471: Correct docs for queue shutdown (python#115838)
Since Python 3.13, shutdown queues raise a `QueueShutDown` exception.
build: bump requires-python to >=3.13; use stdlib Queue.shutdown()
Jean-Luc-Picard-2021 commentedon Aug 18, 2026
Would it be possibly to add "shutdown" also to Threading.join etc..
Basically replicating the exception signature throws InterruptedException
from Java. Or what is the Pythonesk approach to get out of Threading.join ?
Similarly for Semaphores. Basically extending the concept introduced
here from Queues, to other concurrency elements such as the more
simpler Semaphores and even Threads itself. BTW: Didn't check whether
my feature request has a duplicate and whether this is the right place.
gvanrossum commentedon Aug 18, 2026
@Jean-Luc-Picard-2021 Please start a discussion on Discord if you want your suggestion to be heard.
Jean-Luc-Picard-2021 commentedon Aug 21, 2026
Thx, I have 99 problems but not getting heard is none of mine.
Proof: See comment above from former BDFL himself.
But it would be more helpful to hint why I should move
to discord. Does Python not anymore use GitHub, Discourse, etc..?
BTW: I don't have a Discord account, because of social media
inflation, and sometimes ticket systems and not discussions are
used for feature requests and/or roadmaps. Because of cohesion.
EpicWink commentedon Aug 21, 2026
@Jean-Luc-Picard-2021 CPython and most PSF projects use Discourse to discuss proposals. Discord is a quick way to talk to people for design suggestions before creating a Discourse topic, but in my opinion can be skipped if you have a concrete enough proposal to debate with.
pythongh-96471: Reimplement multiprocessing.Queue.shutdown()