Thread._stop() behavior changed in Python 3.4

[Ian Kelly]

On Mar 17, 2014 12:53 PM, "Jurko Gospodnetić" <jurko.gospodnetic at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20140317/bd436834/attachment.html>