Add tornado.queues.

[ajdavis]

This is consistent with the latest API for asyncio. It raises special QueueFull and QueueEmpty errors instead of the standard Queue.Full and Queue.Empty, and there is no separate JoinableQueue, see Tulip issue 220.

LifoQueue and PriorityQueue will come next.

[bdarnell]

This is an unfortunate precedent: channels with a zero bound (so a put() can only proceed when there is a waiting get()) have proven surprisingly useful in Go. But given the precedent, we should keep 0 as unbounded and use a separate class or option for zero-bounded queues if we introduce them (and I'd need to think more about whether zero-bounded queues can make sense without the select statement).

[ajdavis]

That sounds like very interesting future work. Incidentally, maxsize=0 once worked this way in Gevent, and they changed to match the standard Queue, introducing "Channel" instead:

http://www.gevent.org/whatsnew_1_0.html#api-changes

[bdarnell]

Yeah, a separate class probably makes the most sense. IIRC go has three different channel implementations and picks one based on the capacity (0, 1, or other)

[ajdavis]

New patch.

[bdarnell]

We need to cancel the timeout when the operation resolves; see the pattern used in gen.with_timeout. (also applies to get(), and we should double-check all the timeouts in locks.py).

[ajdavis]

Oops. Fixed in this PR for queues, will submit a separate PR for locks.