Thread._stop() behavior changed in Python 3.4
Felix Yan
felixonmars at gmail.com
Mon Mar 17 13:59:52 EDT 2014
More information about the Python-list mailing list
Mon Mar 17 13:59:52 EDT 2014
- Previous message (by thread): Thread._stop() behavior changed in Python 3.4
- Next message (by thread): Thread._stop() behavior changed in Python 3.4
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: <http://mail.python.org/pipermail/python-list/attachments/20140318/3c7f0c7a/attachment.sig>
- Previous message (by thread): Thread._stop() behavior changed in Python 3.4
- Next message (by thread): Thread._stop() behavior changed in Python 3.4
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list