The reliability of python threads

[Klaas]

On Jan 24, 5:18 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> "Klaas" <mike.kl... at gmail.com> writes:
> > CPython is more that "a particular implementation" of python,

> It's precisely a particular implementation of Python.  Other
> implementations include Jython, PyPy, and IronPython.

I did not deny that it is an implementation of Python.  I deny that it
is but an implementation of Python.

Jython: several versions behind, used primariy for interfacing with
java
PyPy: years away from being a practical platform for replacing CPython
IronPython: best example you've given, but still probably three or four
orders of magnitude less significant that CPython

> >  and the GIL is more than an "artifact".  It is a central tenet of
> > threaded python programming.

> If it's a central tenet of threaded python programming, why is it not
> mentioned at all in the language or library manual?

The same reason why IE CSS quirks are not delineated in the HTML 4.01
spec.  This doesn't mean that they aren't central to css web
programming (they are).

How could the GIL, which limits the number of threads in which python
code can be run in a single process to one, NOT be a central part of
threaded python programming?

> The threading
> module documentation describes the right way to handle thread
> synchronization in Python, and that module implements traditional
> locking approaches without reference to the GIL.

No-one has argued that the GIL should be used instead of
threading-based locking.  How could they? The two concepts are not
interchangeable and while they affect each other, are two different
things entirely.  In the post you responded to and quoted I said:

> > I don't advocate relying on the GIL to manage shared data when
> > threading, 

-Mike