This seems like a useful idea. I recommend to write a test implementation and play with it.


Andrew:
> I think the proposal makes the queues API more error-prone: concurrent put() and close() produces unpredictable result on get() side.

How? Can you elaborate?


Caleb:
> I'm interested in how this change would affect the pattern of shutting down a queue-processing task.

Agree, this can be useful for that.


Martin:
> Given the reactions I gather "close" is a better name for the method, so I changed it accordingly.

Not sure I like "close" since it will *cancel* all getters and putters & discard all items in the queue AND allow further operation on the queue.  The latter part is really questionable -- what's the point of losing the data in the queue and resuming it?  Seems like a mechanism for writing unreliable code, but perhaps you can give us an example where this is necessary.