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.

Author rhettinger
Recipients davin, mwf, rhettinger, tim.peters
Date 2017-03-04.07:11:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1488611517.31.0.223161903373.issue29701@psf.upfronthosting.co.za>
In-reply-to
Content
Notes:
------

* Ruby has a Queue.close() method like the one being proposed here.  There is also a ?closed() call for testing the status:  https://ruby-doc.org/core-2.3.0/Queue.html

* Java queues do not have a closing method: https://docs.oracle.com/javase/8/docs/api/java/util/AbstractQueue.html

* This idea came up once for Python on StackOverflow.  The was little interest and the OP selected his own answer.  Concrete use cases were not discussed.  http://stackoverflow.com/questions/3605188/communicating-end-of-queue

* C# message queues have a close() method but it behaves much differently (it frees resources, doesn't raise exceptions, and will reacquire resources if used again).

* The Bull project NodeJS accessing Redis has a close() method for queues.  Its purpose is to perform a graceful shutdown of a remote service.  There doesn't seem to be a parallel using for Python threads (though it might make sense for async).  This use seems more akin to a connection.close() for databases. https://github.com/OptimalBits/bull#close

Open Questions
--------------

* Is try/except logic in a consumer preferable to the if-logic that would be used with a sentinel object.

* What the right vehicle for communicating out-of-band information like a requests for a consumer to shutdown-when-queue-empty, shut-down-immediately, restart, clear, pause-consumption, or reset?  Should there be a shared variable that consumers would monitor?  Should the communication be through a message in the queue itself?  Should there be a way to inject an exception much like a generator.throw()? 

* Do we have any concrete examples from real code that we could study to help inform the design decision?

* If there are concrete use cases, are they common or rare?  If it is rare, would it be better to use existing approaches (sending a messages through the queue, checking a shared variable after a timeout, having a second queue for control-flow information, etc).

* How would a producer indicate a reduced need for consumers (I no longer need ten workers, only two will suffice)?
History
Date User Action Args
2017-03-04 07:11:57rhettingersetrecipients: + rhettinger, tim.peters, davin, mwf
2017-03-04 07:11:57rhettingersetmessageid: <1488611517.31.0.223161903373.issue29701@psf.upfronthosting.co.za>
2017-03-04 07:11:57rhettingerlinkissue29701 messages
2017-03-04 07:11:56rhettingercreate