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

Paul Moore p.f.moore at gmail.com
Fri Dec 12 11:03:14 CET 2008

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:

Paul.

More information about the Python-Dev mailing list