An improvement to Queue

[Michael Abbott]

"Alex Martelli" <aleax at aleax.it> wrote in news:a3bqsu$bab$1 at serv1.iunet.it:

> mportant scenario, but why would you want to queue a do-the-work when
> a different queue WAS empty?  The natural point in time at which to
> queue would seem to be "when enough stuff has come from the socket"
> (presumably determined by examining the stuff).
 
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.

If I was examining the stuff coming out of the socket and not doing 
anything at all until I was happy with it, I guess I would indeed queue up 
the incoming text elsewhere and chop it into commands (indeed, that's 
exactly what I do do elsewhere).
    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, so what I do is queue the command and 
let the executer know that it's got some work to do.

Again, the most efficient way to do this is to only tell the client on the 
transition empty->non-empty, because if the client always arranges to take 
everything it can (read until its queue is empty) then I'm guaranteed to be 
able to keep things flowing with the minimum of events.


This is, after all, fairly standard hardware interrupt stuff: a buffering 
device will typically interrupt once when its buffer becomes non-empty, and 
only re-enable the interrupt once the buffer has been emptied (or the 
interrupt has been cleared in some other explicit fashion).