An improvement to Queue

[Tim Peters]

[Michael Abbott]
> It's the transition from empty to non-empty that's important: I know that
> the consumer will consume until there's nothing left (that's part of the
> contract), and the producer should be able to promise not to pester the
> consumer until it has finished its previous round of work.

It *sounds* like you're using Queue to manipulate items at too low a level
of granularity.  If you created a class to encapsulate the notion of "one
round of work", then the consumer could pull off "one complete round of
work" per Queue.get(), and you wouldn't need other synch gimmicks (or other
complications) to communicate where "one round of work's" boundaries lie.

> ...
> However, the question is: what am I going to do with a command that's
> ready to be executed?  The problem is, the code that's going to obey the
> command might not be ready for it,

If the consumer pulls off a "one round of work" object, then presumably it
won't *try* another Queue.get() until it is ready for another round of work.
Queue exists to mediate potentially mismatching flow rates, not to supply a
brittle way to perform aggregation <wink>.