[Python-3000] the future of the GIL

[Talin]

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