This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: runnig thread multiple times
Type: enhancement Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: makaron, spiv, tim.peters, tzot
Priority: normal Keywords:

Created on 2003-08-23 09:09 by makaron, last changed 2022-04-10 16:10 by admin. This issue is now closed.

Messages (9)
msg17883 - (view) Author: Grzegorz Makarewicz (makaron) Date: 2003-08-23 09:09
Internal variable __started remains set to True/1 even
if thread is already terminated, this situation will
generate assertion error when .start is invoked second
time.

demo.py

import time
import threading

done = threading.Event()
def demo():
	print 'bip'
	done.set()

t=threading.Thread(target=demo)
t.start()
while not done.isSet():
	time.sleep(0.1)
done.clear()
print 'returned'
t.start()
msg17884 - (view) Author: Χρήστος Γεωργίου (Christos Georgiou) (tzot) * Date: 2003-08-29 09:07
Logged In: YES 
user_id=539787

This is documented behaviour, therefore not a bug (see 
http://www.python.org/doc/current/lib/thread-objects.html , 
doc for the start() method).

The designed methodology is to create a new 
threading.Thread object to start a new thread.

Why re-start a thread anyway?  Optimisation of resources?  
IMHO that would be minor, if existant at all.
msg17885 - (view) Author: Andrew Bennetts (spiv) Date: 2003-08-29 13:07
Logged In: YES 
user_id=50945

Also, how would 'someThread.join()' work if threads could be
restarted?

The current situation seems fine to me -- I can't think of a
use-case for this that isn't satisfied by either having an
idiomatic worker thread, or just simply creating a
completely new thread.

Presumably the rationale for wanting restartable threads is
performance, i.e. avoiding setup/teardown costs of threads
-- but this goal is better served by typical worker threads
blocking on a Queue.Queue anyway, i.e.:

    def worker(queue):
         while 1:
             job = queue.get()
             # ...

     q = Queue.Queue()
     t = threading.Thread(target=worker)

In my opinion, the current situation is fine and this
proposal isn't carefully thought out, so thsi bug can be
resolved as "won't fix".

[I seem to recall a bug very similar to this being rejected,
but I can't find it now]
msg17886 - (view) Author: Grzegorz Makarewicz (makaron) Date: 2003-08-29 13:43
Logged In: YES 
user_id=115179

Since threads are controlled by __start/__stop so there is
no chance to start already running thread.

For me this is perfectly legal - thread was started and has
been terminated, so why not start it second time ?

Queue blocks on use and cant be released/signaled, when it
is used inside thread so thread is blocked too. On windows
platform process is terminated when all its threads are
terminated too - we have deadlock.

example where program hangs on exit:

import time
import threading
import Queue

thqueue = Queue.Queue()
thevent = threading.Event()

def t():
	thevent.set()
	item = thqueue.get()

threading.Thread(target=t).start()

while not thevent.isSet():
	time.sleep(0.1)
print 'exit'
msg17887 - (view) Author: Χρήστος Γεωργίου (Christos Georgiou) (tzot) * Date: 2003-08-29 14:53
Logged In: YES 
user_id=539787

This is a different issue (blocked threads preventing program 
exit on a specific platform).  You might consider that as a 
platform-specific bug, one for which little can be done 
unfortunately (until Python OS starts spreading :).

It is sound advice to make sure you send an finalising token 
to threads waiting on a Queue, which directs them to end.  
No platform-specific hassles this way.

For your issue, a typical solution would be to wrap your 
threads in a class, which allows you to 'restart' threads (while 
actually creating a new threading.Thread).

Please understand that personal opinions are not enough to 
justify changes to the language (unless the same personal 
opinions belong to a clear majority of the Python community); 
all requesters need to justify their requests on a practical 
point of view, or provide code that does what they want 
without disrupting the language operation.

Since "bug" 793687 is actually documented behaviour, you 
might consider closing and reposting it as a feature request; 
hopefully you will provide a patch too :)
msg17888 - (view) Author: Grzegorz Makarewicz (makaron) Date: 2003-08-29 15:58
Logged In: YES 
user_id=115179

Blocking on exit isnt platform specific, it looks like done
by design - linux hangs too (py2.2, redhat).
msg17889 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2003-08-29 17:26
Logged In: YES 
user_id=31435

Yes, blocking on exit is by design.  Quoting the docs (always 
the last place to look <wink>):  "The entire Python program 
exits when no active non-daemon threads are left.".  If you 
don't want exit to wait for a specific thread T to stop, call 
T.isDaemon(True) *before* calling T.start().
msg17890 - (view) Author: Grzegorz Makarewicz (makaron) Date: 2003-08-29 18:21
Logged In: YES 
user_id=115179

:) over last 8 years I'm reading it every weekend and every
time I find somthing usefull.

Thanks for clarification
msg17891 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2003-08-31 02:15
Logged In: YES 
user_id=31435

It can help to read Java's thread docs too, since Guido based 
threading.py on Java's thread model.  For example, that's 
where the distinction related to daemon threads comes from.  
It's also why a Python threading.Thread can transition from 
alive to not alive at most once, for that matter.
History
Date User Action Args
2022-04-10 16:10:48adminsetgithub: 39111
2003-08-23 09:09:52makaroncreate