Parallelization on muli-CPU hardware?

[Neil Hodgson]

Luis P Caamano:

> Therefore, fixing the GIL was always in competition with existing code
> and libraries, and it always lost because it was (and still is)
> considered "not worth the effort."

   Greg Stein implemented a "free-threaded" version of Python in 1996 and
had another look in 2000.

http://python.tpnet.pl/contrib-09-Dec-1999/System/threading.README
http://mail.python.org/pipermail/python-dev/2000-April/003605.html

    So, it is not the initial implementation of a GIL-free Python that is
the stumbling block but the maintenance of the code. The poor performance of
free-threaded Python contributed to the lack of interest.

> That's probably the main disagreement I have
> with those that think that the GIL is not a big problem, IPC is not a
> solution but a workaround.

   For me, the GIL works fine because it is released around I/O operations
which are the bottlenecks in the types of application I write.

>   - Let users lock, not the interpreter.  If you use threads and you
> access global objects without locking, you might get undefined
> behaviors, just like in C/C++.

   That will cause problems for much existing code.

> Unfortunately, those changes are big enough that I don't think they'll
> happen under the CPython source tree even we all wanted them.

   It won't happen until the people that think this is a problem are
prepared to provide the effort to maintain free-threaded Python.

   Neil