Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed4a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <CAPTjJmrNizyUvY=XC+FwKcTv+TDMKQv9YL6dyc3WjiGDtB+6iw@mail.gmail.com>
References: <279038900.uDlbjECTej@felix-arch> <CAPTjJmrNizyUvY=XC+FwKcTv+TDMKQv9YL6dyc3WjiGDtB+6iw@mail.gmail.com>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Mon, 17 Mar 2014 12:03:51 -0600
Subject: Re: Thread._stop() behavior changed in Python 3.4
To: Python <python-list@python.org>
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.8212.1395079481.18130.python-list@python.org>
Lines: 41
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:68445

On Mon, Mar 17, 2014 at 11:40 AM, Chris Angelico <rosuav@gmail.com> wrote:
> Antoine says that this doesn't even stop the thread
> (I can't say; I've never used _stop(), for obvious reasons), so this
> code was doubly broken.

I was curious about that -- after all, Python's threads aren't truly
concurrent, so perhaps they could just test the flag each time they
resume -- so I tested it using 3.3.  First I tried simply adding a
print call on to the end of the OP's function:

>>> def stale():
...     import time
...     time.sleep(1000)
...     print('hello')
...
>>> t = threading.Thread(target=stale)
>>> t.start(); t._stop()

No output was printed, so at least a sleeping thread can apparently be
stopped.  Then I tried removing the sleep call:

>>> def stale():
...     for i in range(10): print('hello')
...
>>> t = threading.Thread(target=stale)
>>> t.start(); print('Starting'); t._stop(); print('Stopping')
hello
Starting
Stopping
>>> hello
hello
hello
hello
hello
hello
hello
hello
hello

So yes, despite the lack of true concurrency, a thread can continue to
run after its _stop has been called.