[Python-Dev] The endless GIL debate: why not remove thread support instead?

[Paul Moore]

2008/12/12 Sturla Molden <sturla at molden.no>:
> Last month there was a discussion on Python-Dev regarding removal of
> reference counting to remove the GIL. I hope you forgive me for continuing
> the debate.
[...]
> Python could be better off doing what tcl does. Allow each process to
> embed multiple interpreters; run each interpreter in its own thread.
> Implement a fast message-passing system between the interpreters (e.g.
> copy-on-write by making communicated objects immutable), and Python would
> be closer to Erlang than Java.

Too much to comment individually here, but I'd agree that
message-passing approaches are a better model in general. Some
specific points:

1. The Queue module gives the bones of a message-passing model,
building something based on that is possible now (and may already
exist). You have to do isolation by convention rather than having it
enforced by the system, but that's OK for coding. (It doesn't help the
"remove the GIL" debate, though).
2. I'd like to see isolation based on multiple interpreters, but the
problem lies with extensions (and at a lower level with the Python C
API) which wasn't designed with isolation in mind. Changing that may
be nice, but it's probably too late (or if not, it's likely to be a
lot of work to do it in a compatible manner).
3. Exposing multiple interpreters at the Python level would let most
of this be done outside the core. But it may result in pure Python
code being able to crash the application if not done carefully.

And of course, the overriding points:
- This needs to be done in a backward compatible manner (Python 3.0 is out now!)
- A working patch is hugely more likely to make progress, as all the
evidence shows that the current core developers don't find this issue
important enough to spend their limited coding time on.

Paul.