After a call to join() method on a Threading.thread object,there is no
way to successfully call start() method on it.

Indeed, the __started flag is not reset in the theading.Thread join()
method.
Since the start() method checks for __started flag , this flag is always
true after a first start, despite the thread was effectively stopped by
the join() call

Since it's perfectly legal to store a threading.Thread object in a
variable or an object member, i think the join() behaviour is odd
because it prevents instance reusability.

From the documentation:
http://docs.python.org/dev/library/threading.html#threading.Thread.start
start() must be called at most once per thread object.

I think this will not change: when a system thread terminates, you
cannot restart it; you have to create another thread.
The same argument applies to threading.Thread. It would be surprising
that this object can represent multiple system threads.

You should create and start different Threads each time.

Hi Amaury,

to me,Thread objects are meant to be abstract representation of a processing that will occur in a separate execution unit at thread start time.
Indeed, that's what the following text (from the link you provided tries to explain)

"Once a thread object is created, its activity must be started by calling the thread’s start() method. This invokes the run() method in a separate thread of control."

So, the 'System Thread' is only created at start() call (which is a good implementation choice)
Moreover, the join() method (when completed) will wait for the System Thread to be disallocated.

However, the Thread object instance and the processing bound to it are still valid.

So in an object oriented point of view, (and syntactically too) , it should be valid to reuse the object (and so repeat the processing bound to it) as many times as necessary without the need to create a new instance as long as the Thread object state is not Alive.

What suprises me , is that the current implementation of threading.Thread (apart from the __started flag behaviour) is compatible with that point of view and i see no limitations (apart that bug) preventing such a use of threads.

I think the threading API will provide better 'high-level' view if it didn't depend on low level considerations (as the dependency on the existence / reusability of the peer System Thread that will be used to effectively host the code execution)

Regards,

Sebastien

Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

I agree with Amaury. This all works exactly as it should work, and will
not change.