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

Josiah Carlson jcarlson at uci.edu
Sun May 6 03:29:31 CEST 2007

"tomer filiba" <tomerfiliba at gmail.com> 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).

There are many solutions to handling the scaling of Python on multicore processors, only one of which is killing the GIL. Another is Greg Ewing's ideas offered in the "Ideas towards GIL removal" thread in the python-ideas list.

My personal favorite, because it doesn't require a complete re-design of the CPython runtime, is better abstractions. I was skeptical at first, but in reading the documentation, installing, testing, and monkeying around with the processing package by Richard Oudkerk, I do think that it has the proper level of abstraction. Like thread programming it has its quirks, but it seems that one should be able to apply much of their experience with threads to the processing module (as long as they rely on explicitly shared objects for communication).

If you are used to using threads, give the processing package a try. You may be as pleasantly surprised as I was. Note that it would take some more work to get it to work with passing sockets to another process, but that has been done before (I have code that others have written if anyone is curious).

More information about the Python-3000 mailing list