In praise of Python's Global Interpreter Lock

September 16, 2007

It's common to say bad things about the GIL (a round of GIL bashing happened recently, for example). I have a contrarian view: I think that the GIL is the right thing for Python.

Python needs some concurrency support, if only so that it can make inherently blocking operations into non-blocking ones. At the same time, the thread and shared memory based concurrent programming model is a terrible one that programmers should avoid as much as possible.

The GIL is good enough and simple enough to easily do the former (in fact it's the only thing you should use the GIL for), while being crappy enough to discourage programmers from writing actual thread and shared memory based concurrent programs, partly because their programs don't get much benefit.

Worse thread support would make the blocking to non-blocking transformation too painful. Better thread support would tempt Python programmers into more actual thread-based concurrent programming, with the attendant heartburn. The GIL sits in a sweet spot in the middle: just good enough to be useful yet pointless enough to not be used.

(In the process the GIL optimizes for the single-threaded case, which is likely to be the most common one for quite some time even in the theoretical glorious multi-core future.)

The GIL also means that the core Python developers are not forced to spend a lot of effort supporting a model of concurrency that will ultimately be a dead end. (If shared memory threading is not a dead end for most concurrency work, we are in a lot of trouble.)

Written on 16 September 2007.
« Weekly spam summary on September 15th, 2007
How mmap(2) requires a unified buffer cache »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Sep 16 22:34:50 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.