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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
