[Python-3000] the future of the GIL

[Josiah Carlson]

"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).


 - Josiah