Issue793687
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.
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) * | 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) * | 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:48 | admin | set | github: 39111 |
2003-08-23 09:09:52 | makaron | create |