[Python-3000] Kill GIL?
ross at sourcelabs.com
Mon Sep 18 06:06:34 CEST 2006
I know it is a bit old, but would Python Object Sharing (POSH)
http://poshmodule.sourceforge.net help you? Also, if you think you like the
current state-of-the-art threading model, you might not after reading this:
This goes to an article on http://www.computer.org with a long URL entitled
"The Problem with Threads."
After some initial surprise when I learned about it, I'm now okay with a GIL
or even single threaded python (with async I/O if necessary). In my opinion
threaded programs with one big shared data space (like CPython's) are
fundamentally untestable and unverifiable, and the GIL was the best solution
to reduce risk in that area. I am happy the GIL exists because it forces me
to come up designs for programs and systems that are easier to write, more
predictable both in terms of correctness and performance, and easier to
maintain and scale. I think there would be significant backlash in the
Python development community the first time an intermittent race condition
or a deadlock occurs in the CPython interpretor after years of relying on it
as a predictable, reliable platform.
I'm also happy the GIL exists because it forces alternative ideas like
Twisted and stackless to be developed and tried.
If you have shared data that really benefits from synchronized access and
updates, write an extension, release the GIL at the appropriate places, and
do whatever you want in a C data structure. I've done this when necessary
and think it is the best of both worlds. I guess I'm assuming this will
still be possible in Python 3000 (I haven't been on the list that long,
There has to be a better concurrency model than threads. Let's design for
the future with useful packages that implement the best ideas of today for
scaling well without threads.
More information about the Python-3000