[pypy-dev] Thinking about the GIL

Amaury Forgeot d'Arc amauryfa at gmail.com
Mon Mar 14 20:19:53 CET 2011


Hi,

2011/3/14 Timothy Baldridge <tbaldridge at gmail.com>:
> I guess I'm missing something, but what's wrong with simply ripping
> out the GIL? In C# we have threads, C FFI (via PInvoke), and never
> have any major issues with threading. It seems to me that the GIL is
> only needed because assumptions were made when writing the
> interpreter. I don't know if it's full of global variables or
> something, but can anyone explain why a GIL is needed at all? I've
> done quite a bit of multi-threading programming, and I fail to see the
> need for a GIL.

The GIL greatly simplifies multi-threaded programming in Python.
For example, you are guaranteed that someList.append(x) won't run into
some race condition and crash the program.

In CPython, simply incrementing the reference count of an object needs some
synchronization between threads. And in PyPy, garbage collectors are
not (yet) thread-safe.

See better explanations about the GIL in CPython:
http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock
http://effbot.org/pyfaq/can-t-we-get-rid-of-the-global-interpreter-lock.htm

-- 
Amaury Forgeot d'Arc



More information about the Pypy-dev mailing list