Mr. Rossum, tear down that GIL!
Effectively, this means that all access to Python objects is serialized, no matter how many threads you have in your program, and no matter how many CPUs or cores you have in your hardware! Python has a really easy to use threading API, which makes multi-threaded programming quite painless. Sadly, the Python interpreter itself makes it impossible for those threads to properly take advantage of the hardware which is common these days.
As the developer of a threaded application that uses lots of Python objects, I’d love to have it take better advantage of multiple cores. However, CPython’s best feature is its integration with C. Even with the ultra-simple GIL threading model, I’ve run into troublesome threading bugs in both Python itself and in a certain excellent extension that’s considered mature. Reliability and language features are much more important to me than threaded performance of the Python interpreter. This is especially true given that most of my performance-sensitive code is written in C and that fine-grained locking would probably be a lose for applications with less innate parallelism. Thus, I think Guido is correct to keep the existing CPython design and focus on improving the language and libraries, leaving different threading architectures to alternative Python implementations. Interestingly, Ruby is switching from green threads to a GIL.
Update: Guido van Rossum responds and references Greg Stein.
2 Comments RSS · Twitter
[...] Michael Tsai weighs in on the "open letter". Share and Enjoy: These icons link to social bookmarking sites [...]
