Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #68444
| From | Felix Yan <felixonmars@gmail.com> |
|---|---|
| Subject | Re: Thread._stop() behavior changed in Python 3.4 |
| Date | 2014-03-18 01:59 +0800 |
| References | <279038900.uDlbjECTej@felix-arch> <loom.20140317T182601-605@post.gmane.org> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.8211.1395079205.18130.python-list@python.org> (permalink) |
[Multipart message — attachments visible in raw view] - view raw
On Monday, March 17, 2014 17:33:09 Antoine Pitrou wrote: > Hi, > > Felix Yan <felixonmars <at> gmail.com> writes: > > A minimized snippet to reproduce: > > > > #!/usr/bin/python > > import threading > > > > def stale(): > > import time > > time.sleep(1000) > > > > t = threading.Thread(target=stale) > > t.start() > > t._stop() > > > > This works correctly with Python 3.3, the program exits immediately after > > t._stop() called, and no exception was raised. > > Basically what you are doing is abusing a private method because you want > to make the thread daemonic after it was started (a daemonic thread is > not waited for at interpreter exit). Please do note one thing: the _stop() > method does *not* actually stop the thread; it just marks it stopped, but > the underlying OS thread continues to run (and may indeed continue to > execute Python code until the interpreter exits). > > So the obvious "solution" here is to mark the thread daemonic before > starting it. > > A possible related improvement would be to relax the contraints on > Thread.daemon to allow setting the flag on a running thread? > > That said, daemon threads (or abuse of the _stop() method as you did) can > lead to instabilities and oddities as some code will continue executing > while the interpreter starts shutting down. This has been improved but > perhaps not totally solved in recent interpreter versions. A fully correct > solution would involve gracefully telling the thread to shut down, via a > boolean flag, an Event, a file descriptor or any other means. > > (if you are interested in this, please open a new issue at > http://bugs.python.org) > > Regards > > Antoine. Thanks for the detailed explanation! Actually I didn't used _stop() myself either, but noticed the problem when trying to build paramiko against python 3.4. Thanks especially for the tip that the threads may be still running - actually I didn't even think about this part! For now I just skipped the test suites for paramiko to get the packaging done (since the test suites themselves are passed without a problem, just the test script made something wrong). I'll try to follow up the issue for paramiko :) Regards, Felix Yan
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: Thread._stop() behavior changed in Python 3.4 Felix Yan <felixonmars@gmail.com> - 2014-03-18 01:59 +0800
csiph-web