Queue qsize = unreliable?
me at privacy.net
Sat Aug 7 15:21:20 CEST 2004
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).
Never play leapfrog with a unicorn.
More information about the Python-list