The question is not and never has been "Does the GIL have undesirable characteristics?" It has always been "can someone produce an implementation that is missing the GIL and actually better, while meeting all the needs CPython has?" So far, the answer is no, despite rather a lot of smart people trying.
(Also note that many people have succeeded by dropping the second clause. Many non-CPython Python implementations don't have a GIL. But they aren't CPython, which in particular means that extensions written for CPython don't work in them, which is really the key thing that distinguishes CPython from just generic "Python".)
I don't think that he is arguing the the GIL isn't a limitation, just that the fundamental limitation it imposes can't be removed without also changing the threading model or the garbage collector. It's really impossible run threads in parallel with any sort of performance when they're all constantly generating a huge amount of cache coherency traffic by updating reference counts.
He's not saying that. He's saying that the GIL isn't a limitation to certain kinds of application, the kinds that Python usually is used for. The kinds of applications where the GIL would be a limitation, Python also has another limitation: slow performance, and performance is usually the reason to run things in parallel.
With PyPy the performance will get better, and they also have a GC, so that hinder is removed. I don't really know if PyPy has a GIL, I would guess that they don't.
"With PyPy the performance will get better, and they also have a GC, so that hinder is removed. I don't really know if PyPy has a GIL, I would guess that they don't."
Ok, the PyPy FAQ says: "Yes, PyPy has a GIL. Removing the GIL is very hard. The first problem is that our garbage collectors are not re-entrant."
Is it really necessary for the GC to be re-entrant to run the interpreter in parallel? Couldn't you have the interpreter running in parallel and then when there is a need to run the GC you have a global GC lock that prevents all threads from running - a stop the world GC. The application runs for a longer time than the GC, right? So it would be a win and a step in the right direction? I believe the early Java mark and sweep GC was like that, and then later Sun developed several different kinds of concurrent and parallel GCs.
> Official PyPy Status Blog
Oh I read that every time they write something. :) But I started reading it in late 2010 and I haven't gone back to the archives, I guess it's time to do that. Thanks for the links.
GIL is a problem - that has been acknowledged every time it has been brought up. There has been past attempts to remove the GIL - that slowed down the interpreter and the patch wasn't merged.
Removing GIL is massive work and will make the interpreter complex. Meanwhile, you have gevent, multiprocessing, c extensions... to work out the limitations.
Not that the case isn't well argued, but to claim that GIL isn't a fundamental limitation and a bad thing is silly.
A few years from now it will be like, "Oh, yeah.. that".