homepage

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)?