Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #68444 > unrolled thread

Re: Thread._stop() behavior changed in Python 3.4

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Thread._stop() behavior changed in Python 3.4 Felix Yan <felixonmars@gmail.com> - 2014-03-18 01:59 +0800

#68444 — Re: Thread._stop() behavior changed in Python 3.4

[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

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web