Thu, 28 Jun 2007
Python Global Interpreter Lock approach: Validated?
It's nice to see Python come out on top for threading.
--titus
posted at: 06:51 | path: /jun-07 | 4 comments
Comments:
Posted by Scott Lamb at Thu Jun 28 09:32:27 2007:
Hmm, I wouldn't call "better than Perl" validation. "Easier to read the Perl, better threading support than COBOL, more productive than TriMedia VLIW assembler, faster than MUMPS!" We can do better than that...
Posted by Titus Brown at Fri Jun 29 07:58:56 2007:
I think you guys are underestimating the damage done to Python's rep on account of the GIL. It's not easy to explain why the GIL is such a good idea, and this is an example-in-the-wild of precisely why.
--titus
Posted by manuelg at Fri Jun 29 11:59:54 2007:
If a threading implementation gives up:
* some latency
to gain:
* throughput
* ease of use
* simpler implementation
* use of C library native OS threads
* and of course, correctness is a must
That would be a wise thing to do!
That is what the GIL does. Gives up some latency, to gain a lot of desirable properties for a threading implementation.
I wish the GIL:
* wasn't global across different interpreter running in the same process
* wasn't the one and only one mechanism to handle the parts of the CPython interpreter that are not thread safe
* didn't need to be invoked so much (the GIL is used for a lot of pointless reference counting bookkeeping for immutable objects shared between threads, like integer objects, objects representing the classes, etc.)
But, on the whole, not bad.