Thread limits?

[François Pinard]

[Tim Peters]

> > Could the above sentence be added to the documentation?  So, we could
> > more definitely rely on it, and there would be no place for confusion.

> I leave that decision to Fred Drake, who I've copied on this.  [...] Since
> anyone reading the docs without that background would read "FIFO" and
> *think* "FIFO", I believe the docs give an accurate story already.

Fair enough, really! :-)

> [François Pinard]
> > If the queue behaves like a FIFO (which you confirmed in your reply)
> > and is empty, I would think it is reliable to say that all real
> > requests have been processed.

> Yes -- although, as the docs say, Queue.qsize() is not reliable!  There's
> simply no way to tell whether a Queue object is empty short of building
> another protocol on top of it.

I would be tempted to think that after having put queue requests,
Queue.qsize() is reliably not empty until some requests get removed from
the queue, and also, that Queue.qsize() will reliably not return zero
before the queue actually returns empty at least once.

>From the documentation, I inferred that the unreliability of Queue.qsize()
only comes from the fact that the other threads come into action between
the measure of the queue, and the use of that measure.

> I don't know why you're so keen to avoid the thread.join() loop, which is
> *obviously* reliable.

Just to avoid maintaining a list of threads, maybe?  Surely not a big deal!
But the real truth, which I reveal because I'm always trying to be honest,
is that I learned how to use `join()' only later :-).

> So it's simply good practice to wait for the threads to clean up after
> themselves first, and an explicit .join loop is the obvious way to do that.

Agreed.  I also found very convenient that we can .join() many times,
it greatly simplifies things.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard