# Queue termination further design

**URL:** <https://discuss.python.org/t/queue-termination-further-design/26630>\
**Category:** Ideas\
**Created:** [May 10, 2023, 4:25am UTC](https://discuss.python.org/t/queue-termination-further-design/26630 "2023-05-10T04:25:44Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![EpicWink](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/epicwink/32/17968_2.png) [@EpicWink](https://discuss.python.org/u/EpicWink)\
**Post date:** [April 18, 2024, 12:47am UTC](https://discuss.python.org/t/queue-termination-further-design/26630/13 "2024-04-18T00:47:53Z")

</div>

Update on multiprocessing queue termination: @YvesDup and I have [notices](https://github.com/python/cpython/pull/104230#issuecomment-2059548365) that the implementation makes it difficult to cleanly implement shutdown without changing the behaviour of the existing implementation. I suggest two options:

- Introduce a new `multiprocessing.queues.TerminableQueue` which simply has the same API as [`queue.Queue`](https://docs.python.org/3/library/queue.html#queue.Queue) (perhaps without `join()` and `task_done()`, as we could add another subclass which uses the existing [`multiprocessing.JoinableQueue`](https://docs.python.org/3/library/multiprocessing.html#multiprocessing.JoinableQueue)’s implementation)

- Change how the current `get()` implementation works by injecting a [select](https://docs.python.org/3/library/select.html#select.select) call before `self._reader.recv_bytes` (`self._reader` is a [`multiprocessing.connection.Connection`](https://docs.python.org/3/library/multiprocessing.html#multiprocessing.connection.Connection) object):

---

_[View the full topic](https://discuss.python.org/t/queue-termination-further-design/26630)._