Thread limits?

[François Pinard]

[Tim Peters]

> If you used the threading module (*not* the "thread" module!) to create
> all your threads, the main thread will automatically wait until all
> child threads (that haven't been marked "daemons" -- see the docs)
> have terminated before it exits.

Yes.  I indeed remember the documentation about daemons.

> > Suppose I'm done with the main application (that is, it
> > distributed all the work it had to) and I want to send each
> > serving thread (N of them) a command so it terminates.

> for i in range(N):
>     your_queue_object.put(object_whose_Deal_With_It_means_Quit)

> > or should it first wait to see that the request queue got empty
> > (meaning that all server threads terminated)?

> That isn't reliable: that the queue is empty merely means that all
> requests have been removed from it, not that even a single one of them
> has been *acted* upon yet.

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.  Each thread did receive a termination request if the
queue is empty, and either has terminated, or is busy terminating itself.

> A common and reliable technique is to save a list of the Thread objects
> you've created, and then do

>     for thread in my_list_of_thread_objects:
>         thread.join()

Yes, this is exactly what I do, _because_ I did not use queues.

> > But the real problem is that I read somewhere than the queued-ness
> > (first-in first-out behaviour) of the Queue class is not guaranteed.  So,
> > it may well happen that server threads receive the termination request
> > early, and all terminate prematurely, leaving the queue forever non-empty.

> Well, I haven't seen that article, but it or you are probably confused
> <wink>.

It was most probably confused, and then confused me! :-)

> The Queue class is "sequentially consistent" from the point of view of
> any single thread.  To make that concrete, if thread T queues X and later
> (the same thread T!) queues Y, X *will* be removed from the queue before
> Y is.

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

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