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

Path	csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!ecngs!feeder2.ecngs.de!novso.com!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Return-Path	<ian.g.kelly@gmail.com>
X-Original-To	python-list@python.org
Delivered-To	python-list@mail.python.org
X-Spam-Status	OK 0.011
X-Spam-Evidence	'H': 0.98; 'S': 0.00; 'cpython': 0.05; 'subject:Python': 0.06; 'exits': 0.09; 'implements': 0.09; 'python': 0.11; 'thread': 0.14; '>>': 0.16; 'bytecode': 0.16; 'called.': 0.16; 'concurrency': 0.16; 'concurrency,': 0.16; 'finishes': 0.16; 'threads.': 0.16; 'underlying': 0.16; 'wrote:': 0.18; 'code.': 0.18; 'not,': 0.20; 'starts': 0.20; 'work,': 0.20; 'print': 0.22; '>': 0.26; 'header:In-Reply-To:1': 0.27; 'instruction': 0.29; 'message-id:@mail.gmail.com': 0.30; 'code': 0.31; 'apparently': 0.31; 'run': 0.32; 'another': 0.32; '(e.g.': 0.33; '(most': 0.33; 'received:google.com': 0.35; 'executing': 0.36; 'next': 0.36; 'performance': 0.37; 'e.g.': 0.38; 'to:addr :python-list': 0.38; 'fact': 0.38; 'pm,': 0.38; 'does': 0.39; 'to:addr:python.org': 0.39; '8bit%:6': 0.40; 'ian': 0.60; 'matter': 0.61; 'charset:iso-8859-2': 0.64; 'pick': 0.64; 'mar': 0.68; 'lack': 0.78; "'true'": 0.84; 'preventing': 0.84; 'time)': 0.91
DKIM-Signature	v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gMnx4JO0FQruI3IBwECMvHNF49dMY3gIXCtF31QeIp0=; b=OMb90ONBA7mwVXRuIwJvrEVFA9XKCdVc/dXy7Sy5Y5M6mESmYCTYoKIX6L0hA1nhtF 7HVffI9JtXQ6Nht5fkA6TB2efBTnpekQ74mcOPnKwVRQLHsStVYOFp2TvuC14rZyqG2k crEcyM4Da0dvxiAciH5dgVI6gSPsVPUnqj25yjl9DpdKJWvjN21JNB6vx6lQoPIr/glN CCssDraF8wJWp+Xgi3nO3WrvSK9DmASq6KEWP/28kimK74jsomaSaY9ludyFMoYxloDl +i7BgyJrSqsSXjYkgpgcHPqW7ubLn5E367ltChfc/jAVEIFM9kINxXtuXtfRDfNX6QQv GtaA==
MIME-Version	1.0
X-Received	by 10.66.141.144 with SMTP id ro16mr6124343pab.131.1395086758935; Mon, 17 Mar 2014 13:05:58 -0700 (PDT)
In-Reply-To	<lg7g6i$qgg$1@ger.gmane.org>
References	<279038900.uDlbjECTej@felix-arch> <CAPTjJmrNizyUvY=XC+FwKcTv+TDMKQv9YL6dyc3WjiGDtB+6iw@mail.gmail.com> <CALwzidkdqEGebjtnAsxGzC0Y1z+k_WZxfSHkBbS9sD6RZy10uQ@mail.gmail.com> <lg7g6i$qgg$1@ger.gmane.org>
Date	Mon, 17 Mar 2014 14:05:58 -0600
Subject	Re: Thread._stop() behavior changed in Python 3.4
From	Ian Kelly <ian.g.kelly@gmail.com>
To	Python <python-list@python.org>
Content-Type	multipart/alternative; boundary=001a1133316cb2810a04f4d2f2a5
X-BeenThere	python-list@python.org
X-Mailman-Version	2.1.15
Precedence	list
List-Id	General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe	<https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive	<http://mail.python.org/pipermail/python-list/>
List-Post	<mailto:python-list@python.org>
List-Help	<mailto:python-list-request@python.org?subject=help>
List-Subscribe	<https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups	comp.lang.python
Message-ID	<mailman.8221.1395086768.18130.python-list@python.org> (permalink)
Lines	67
NNTP-Posting-Host	2001:888:2000:d::a6
X-Trace	1395086768 news.xs4all.nl 2853 [2001:888:2000:d::a6]:37815
X-Complaints-To	abuse@xs4all.nl
Xref	csiph.com comp.lang.python:68458

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

On Mar 17, 2014 12:53 PM, "Jurko Gospodnetić" <jurko.gospodnetic@pke.hr>
wrote:
>
>   Hi.
>
>
> On 17.3.2014. 19:03, Ian Kelly wrote:
>>
>> So yes, despite the lack of true concurrency, a thread can continue to
>> run after its _stop has been called.
>
>
>   Actually 'true' or 'false' concurrency does not matter here.
>
>   CPython supports multiple threads and implements them using underlying
native OS threads. The fact that it has an internal mutex (GIL) preventing
it from executing/interpreting Python code at the same time in multiple
threads (most of the time) does not come into play.. When one thread exits
its GIL protected section (e.g. finishes processing one bytecode
instruction and is about to go on to processing the next one), another
thread may pick up the GIL and do some of its work, e.g. print out some
output.

Yes, and whenever a thread acquires the GIL it *could* check whether its
_stop flag has been set before it starts executing any Python code.
Apparently though it does not, perhaps for performance reasons.

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

Thread

Re: Thread._stop() behavior changed in Python 3.4 Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-17 14:05 -0600

csiph-web