Queue qsize = unreliable?
peter at engcorp.com
Fri Aug 6 18:42:27 CEST 2004
James R. Saker Jr. wrote:
> Perhaps there's an easier way to accomplish what I'm attempting.
James, I can't see anything in your description that requires you to
call qsize() at all, let alone get a "reliable" result.
Is the key hidden somewhere in your last paragraph here? :
> I've done an initial version of this using Postgresql for an
> intermediary (and twisted's database interface to deal with blocking
> issues), but having to load Postgresql on a syslog2beep receptor is
> overkill. A ZODB Queue implemented in a threaded app would seem the
> right way to go. Any thoughts?
The third point seems to just say that you need a Queue and you
need to have that thread sit in a blocking get(). What am I
> 3. have a thread sit and look for data in the queue. when data is
> found, parse it and fire it off using BEEP to an upstream collector.
Note that any time you have a potential consumer that you think
should call qsize() before doing something, you can just have that
consumer do a non-blocking get() instead, so long as it's prepared
to handle the result. Alternatively, trust that qsize() is
reliable to the extent that if it says the Queue has X elements,
then it has at least X elements if you are the only consumer...
More information about the Python-list