Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #68452 > unrolled thread
| Started by | Jurko Gospodnetić <jurko.gospodnetic@pke.hr> |
|---|---|
| First post | 2014-03-17 19:51 +0100 |
| Last post | 2014-03-17 19:51 +0100 |
| Articles | 1 — 1 participant |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Thread._stop() behavior changed in Python 3.4 Jurko Gospodnetić <jurko.gospodnetic@pke.hr> - 2014-03-17 19:51 +0100
| From | Jurko Gospodnetić <jurko.gospodnetic@pke.hr> |
|---|---|
| Date | 2014-03-17 19:51 +0100 |
| Subject | Re: Thread._stop() behavior changed in Python 3.4 |
| Message-ID | <mailman.8217.1395082291.18130.python-list@python.org> |
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.
Best regards,
Jurko Gospodnetić
Back to top | Article view | comp.lang.python
csiph-web