An improvement to Queue

[Jeff Shannon]

Michael Abbott wrote:

> "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: ....
>
> 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.

What I don't get (and what I *think* Alex was asking about, though I hesitate
to speak for him), is..

What's the point of putting an incomplete command event into the queue at all?
If the command isn't complete, then wait to dump it in the queue until it is.
That way, each item in the queue is a complete request;  there's no need for
the consumer to do anything other than grab the next request, and process it.
This is also much more scalable -- if a command is spread across several items
in the queue, then you can only have *one* consumer thread -- because multiple
consumers might each get a fragment of the same command -- and *one* producer
thread -- because otherwise you'll end up with fragments of the same command
interleaved.  (You *could* use some sort of ID-number to track which command
each fragment belonged to, I suppose, but this then creates more work for the
producer, who must be ready to assemble parts of as many different commands at
once, as you have producer threads.)  On the other hand, if every producer only
drops a completed command into the queue, then there's only *one* command to
keep track of;  there's no worry about interleaving fragments, so multiple
producers can each create a single command at a time, and thus all share that
same queue; and any consumer can grab an item from the queue and just go with
it, allowing any number of consumers to share the queue.  There's a whole lot
less inter-thread communication to worry about, so it should greatly simplify
concurrency issues.  If you might have multiple commands being generated at the
same time, then you just set up multiple producer threads, which simplifies the
architecture.

Maybe I'm just being dense (it certainly wouldn't be the first time, nor will
it be the last), but I just can't see *any* reason for putting fragmentary
commands into the queue.

Jeff Shannon
Technician/Programmer
Credit International