Queue qsize = unreliable?

[Peter Hansen]

James R. Saker Jr. wrote:
> Perhaps there's an easier way to accomplish what I'm attempting. 
[snip description]

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
missing?

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

-Peter