Will Python 3.0 remove the global interpreter lock (GIL)

[Terry Reedy]

"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>
| wrote:
| > > No.http://www.artima.com/weblogs/viewpost.jsp?thread=211430
| >
| > Ops, I 
meant:http://www.artima.com/forums/threaded.jsp?forum=106&thread=211200
| >
| > --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
| slow."

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
| 1990's?

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 
speed halved.

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

tjr