[Python-3000] the future of the GIL

[Jean-Paul Calderone]

On Wed, 09 May 2007 12:46:14 +1200, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>Luis P Caamano wrote:
>
>> You gotta finish that sentence, it was a slow down on single CPU with
>> a speed increase with two or more CPUs, leveling out at 4 CPUs or so.
>
>But it's still going to slow down all code that
>doesn't use threads. I don't want to be *forced*
>to use threads to get decent speed from my programs!
>

It would also make Python applications a much greater drag on the
system as a whole, as they would need to use four whole CPUs to
just break even on a multithreaded compute-intensive task.  Even if
this can be improved over time (which it probably can be, to some
extent, given sufficient effort), one might want to consider the
consequences of having any widespread usage of such a resource-
intensive Python interpreter on general perception of Python as a
language.

Having a GIL-free build of CPython alongside a GIL-having build
does something to alleviate this, but it's not immediately what
the development maintenance burden of this would be, nor whether
the resulting user-experience would be desirable (which will be
packaged, what would become of "#!/usr/bin/env python", etc).  It
may be doable, but it doesn't strike me as an obviously good idea.

Jean-Paul