Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #68445
| References | <279038900.uDlbjECTej@felix-arch> <CAPTjJmrNizyUvY=XC+FwKcTv+TDMKQv9YL6dyc3WjiGDtB+6iw@mail.gmail.com> |
|---|---|
| From | Ian Kelly <ian.g.kelly@gmail.com> |
| Date | 2014-03-17 12:03 -0600 |
| Subject | Re: Thread._stop() behavior changed in Python 3.4 |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.8212.1395079481.18130.python-list@python.org> (permalink) |
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.
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: Thread._stop() behavior changed in Python 3.4 Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-17 12:03 -0600
csiph-web