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

Groups > comp.lang.python > #68440

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

Show all headers | View raw

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.

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: Thread._stop() behavior changed in Python 3.4 Antoine Pitrou <solipsis@pitrou.net> - 2014-03-17 17:33 +0000

csiph-web