> Expected: items stay in the queue until a consumer consumes it

That would be my expectation as well.

Davin, do you know why the example in the docs uses queue.Queue() instead of multiprocessing.Queue()?  Would there be a difference?

Also, I'm curious about the best practice for message queues when a consumer is killed.  Even if the message getting is atomic and never loses a message, what do people normally do to resurrect a task that was already underway when the consumer is killed?  I presume there is no easy way to find-out whether the task had just started, was in-process and changed the state of the system, or mostly finished.  Is there some sort of coding pattern for begin_transaction, commit, and rollback?  ISTM, that killing consumers is a perilous business.

The only reliable pattern I can think of is for the consumer to send back messages through another queue to indicate that a task was received and underway, and to indicate that a task was completed.