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/