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: 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: References: <279038900.uDlbjECTej@felix-arch> Date: Mon, 17 Mar 2014 14:05:58 -0600 Subject: Re: Thread._stop() behavior changed in Python 3.4 From: Ian Kelly To: Python 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: 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 --001a1133316cb2810a04f4d2f2a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mar 17, 2014 12:53 PM, "Jurko Gospodneti=C4=87" 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. --001a1133316cb2810a04f4d2f2a5 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable


On Mar 17, 2014 12:53 PM, "Jurko Gospodneti=E6" <jurko.gospodnetic@pke.hr> wrote:
>
> =A0 Hi.
>
>
> On 17.3.2014. 19:03, Ian Kelly wrote:
>>
>> So yes, despite the lack of true concurrency, a thread can continu= e to
>> run after its _stop has been called.
>
>
> =A0 Actually 'true' or 'false' concurrency does not ma= tter here.
>
> =A0 CPython supports multiple threads and implements them using underl= ying native OS threads. The fact that it has an internal mutex (GIL) preven= ting it from executing/interpreting Python code at the same time in multipl= e threads (most of the time) does not come into play.. When one thread exit= s its GIL protected section (e.g. finishes processing one bytecode instruct= ion and is about to go on to processing the next one), another thread may p= ick 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.

--001a1133316cb2810a04f4d2f2a5--