[Python-bugs-list] [ python-Bugs-793687 ] runnig thread multiple times

[SourceForge.net]

Bugs item #793687, was opened at 2003-08-23 11:09
Message generated for change (Comment added) made by makaron
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793687&group_id=5470

Category: Threads
Group: Feature Request
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Grzegorz Makarewicz (makaron)
Assigned to: Nobody/Anonymous (nobody)
Summary: runnig thread multiple times

Initial Comment:
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()


----------------------------------------------------------------------

>Comment By: Grzegorz Makarewicz (makaron)
Date: 2003-08-29 20:21

Message:
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


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-29 19:26

Message:
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().

----------------------------------------------------------------------

Comment By: Grzegorz Makarewicz (makaron)
Date: 2003-08-29 17:58

Message:
Logged In: YES 
user_id=115179

Blocking on exit isnt platform specific, it looks like done
by design - linux hangs too (py2.2, redhat).


----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-08-29 16:53

Message:
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 :)

----------------------------------------------------------------------

Comment By: Grzegorz Makarewicz (makaron)
Date: 2003-08-29 15:43

Message:
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'


----------------------------------------------------------------------

Comment By: Andrew Bennetts (spiv)
Date: 2003-08-29 15:07

Message:
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]

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-08-29 11:07

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793687&group_id=5470