Will Python 3.0 remove the global interpreter lock (GIL)
tjreedy at udel.edu
Wed Sep 19 04:56:41 CEST 2007
"TheFlyingDutchman" <zzbbaadd at aol.com> wrote in message
news:1190164166.378500.155990 at o80g2000hse.googlegroups.com...
| On Sep 2, 5:38 pm, "Eduardo O. Padoan" <eduardo.pad... at gmail.com>
| > > No.http://www.artima.com/weblogs/viewpost.jsp?thread=211430
| > Ops, I
| > --http://www.advogato.org/person/eopadoan/
| > Bookmarks:http://del.icio.us/edcrypt
| "No. We're not changing the CPython implementation much. Getting rid
| of the GIL would be a massive rewrite of the interpreter because all
| the internal data structures (and the reference counting operations)
| would have to be made thread-safe. This was tried once before (in the
| late '90s by Greg Stein) and the resulting interpreter ran twice as
Since Guido wrote that, there have been put forth more ideas and interest
and promises of efforts to remove or revise the GIL or do other things to
make using multiple cores easier. (The later being the point of the
concern over GIL.)
| How much faster/slower would Greg Stein's code be on today's
| processors versus CPython running on the processors of the late
Perhaps a bit faster, though processor speeds have not increased so much
the last couple of years.
|And if you decide to answer, please add a true/false response
| to this statement - "CPython in the late 1990's ran too slow".
False by late 1990's standards, True by today's standards ;-).
Most people are not currently bothered by the GIL and would not want its
In any case, any of the anti-GIL people are free to update Stein's code and
distribute a GIl-less version of CPython. (Or to use Jython or
More information about the Python-list