[Python-3000] the future of the GIL (original) (raw)

Talin talin at acm.org
Sun May 6 02:57:51 CEST 2007

tomer filiba wrote:

the only way to overcome this with cpython is to Kill The GIL (TM), and since it's a very big architectural change, it ought to happen soon. pushing it further than version 3.0 means all library authors would have to adapt their code twice (once to make it compatible with 3.0, and then again to make it thread safe).

i see all hell has broken loose here, PEP-wise speaking, but i really hope there's still time to consider killing the GIL at last.

I've brought up this issue as well, but the consensus seems to be that this is just too hard to even consider for 3.0.

Note that Jython and IronPython don't have the same restrictions in this regard as CPython. Both VMs are able to run in multiprocessing environments. (I don't know whether or not Jython/IronPython even have a GIL or not.)

My suggested approach to making CPython concurrent is to first tackle the problem of garbage collection in a multiprocessing environment. Once that is done, the next piece would be to address the issues of thread safety of the interpreter's internal data structures.

At one point, I started working on a generic, concurrent garbage collector that would be useful for a variety of interpreted languages such as Python, but I haven't had time to work on it lately. Its similar to the Boehm collector, except that it's designed for "cooperative" languages in which the collector knows about the structure of objects.

When I last worked on it, I had gotten the "young generation" collection working, and I had just finished implementing the global heap, and was in the process of writing unit tests for it. I hadn't started on old-generation collection or cross-generation reference tracking.

-- Talin

More information about the Python-3000 mailing list