Queue qsize = unreliable?

[Dan Sommers]

On Sat, 07 Aug 2004 06:14:29 GMT,
Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:

> On Fri, 6 Aug 2004 11:53:11 -0400, Tim Peters <tim.peters at gmail.com>
> declaimed the following in comp.lang.python:

>> 
>> James, why do you think they're necessary functions?  If, e.g., you're

> 	My birth-certificate lists "James" as a saint name, will you
> accept my response <G>

>> worried about the queue getting "too big", pass a maximum size to the
>> constructor, and then a producer thread trying to add to a full queue
>> will block until a consumer thread takes an entry off the queue. 
>> Indeed, mediating mismatched processing rates is a prime use case for
>> bounded queues.
>> 
> 	I can see a potential use for wanting to know the approximate
> size of a Queue. A thread dispatcher with leeway to create additional
> processing threads whenever the Queue becomes full (I'm not quite sure
> how one would handle removing threads later, unless one can Queue the
> removal command). Something like (pseudo-Python):

[ algorithm snipped ]

AIUI, a Queue *can* return its approximate size, which would be almost
good enough for that application.  A full Queue raise an exception when
you try to stuff more into it, and that would work just as well.  OTOH,
not reaching that point might also be nice.

I can envision a naive algorithm thrashing if the Queue is close to the
threshold and the producer and consumer threads are running at about the
same rate, though.  You'd end up with a slightly more interessting
algorithm using high and low water marks rather than a single threshold;
the (programming-language-neutral) details are left to the interested
reader (and, I'm sure, contained in many a textbook).

Regards,
Dan

-- 
Dan Sommers
<http://www.tombstonezero.net/dan/>
Never play leapfrog with a unicorn.