GIL in Python 3.1

python multithreading gil
Dewfy picture Dewfy · Aug 3, 2009 · Viewed 13.1k times · Source

Does anybody knows fate of Global Interpreter Lock in Python 3.1 against C++ multithreading integration

Answer

Alex Martelli picture Alex Martelli · Aug 3, 2009

GIL is still there in CPython 3.1; the Unladen Swallow projects aims (among many other performance boosts) to eventually remove it, but it's still a way from its goals, and is working on 2.6 first with the intent of eventually porting to 3.x for whatever x will be current by the time the 2.y version is considered to be done. For now, multiprocessing (instead of threading) remains the way of choice for using multiple cores in CPython (IronPython and Jython are fine too, but they don't support Python 3 currently, nor do they make C++ integration all that easy either;-).

Related questions

Python Global Interpreter Lock (GIL) workaround on multi-core systems using taskset on Linux?

So I just finished watching this talk on the Python Global Interpreter Lock (GIL) http://blip.tv/file/2232410. The gist of it is that the GIL is a pretty good design for single core systems (Python essentially leaves the thread …

Read More
Green-threads and thread in Python

As Wikipedia states: Green threads emulate multi-threaded environments without relying on any native OS capabilities, and they are managed in user space instead of kernel space, enabling them to work in environments that do not have native thread support. Python's …

Read More
Why is there no GIL in the Java Virtual Machine? Why does Python need one so bad?

I'm hoping someone can provide some insight as to what's fundamentally different about the Java Virtual Machine that allows it to implement threads nicely without the need for a Global Interpreter Lock (GIL), while Python necessitates such an evil.

Read More