Join us and get access to thousands of tutorials and a community of expert Pythonistas.
This lesson is for members only. Join us and get access to thousands of tutorials and a community of expert Pythonistas.
Removing the GIL
While many Python users take advantage of the single-threaded performance benefits of GIL. The multi-threading programmers don’t have to fret as some of the brightest minds in the Python community are working to remove the GIL from CPython. One such attempt is known as the Gilectomy.
00:00 In the previous lesson, I talked about changes to the bytecode and GIL operation over a series of Python releases. In this lesson, I’ll talk about what’s being done about the GIL. So if it gets in the way of good concurrency, why not just get rid of it?
00:14 Well, the short answer is that’s pretty hard. You could do it, but likely not in a fashion that wouldn’t break backward compatibility. If you were writing Python during the Python 2 to 3 transition, you’ll recall how important backward compatibility is to the Python community and how messy it can get when it isn’t there.
00:33 And don’t forget, this backward compatibility goes deeper than just the language itself. It’s also about the extension system.
00:40 The folks at NumPy shouldn’t have to recompile their library or change their code just because there was a release of Python. You want the libraries to be compatible between systems.
00:50 The GIL is there to solve problems with how these libraries interact with reference counting and changing it would mean changing NumPy. Now, multiply that by every single extension package.
01:01 I don’t know how many extensions there are out there, but there are over 500,000 packages on PyPI. Even if only 10% used extensions, that’s 50,000 packages that would need to adjust.
01:12 This goes back to the Python 2 to 3 transition. It took over a year for all the major packages to move to be 3 compatible. Never forget, almost all the work on Python and its libraries is done by volunteers in their spare time.
01:26 And in case, “Hey, it’s hard, maybe you shouldn’t,” isn’t good enough, let’s double down by talking about when it was tried. The Gilectomy was an attempt to remove the GIL.
01:37 It switched the interpreter to using a garbage collector style of memory management similar to what I was talking about in Jython earlier.
01:44 It turned out to be significantly slower in the single threaded case and wasn’t backwardly compatible for libraries. These two facts were enough to kill the attempt.
01:54 It never got merged into the main code branch.
01:58 That said, another attempt is ongoing. PEP 703 is all about removing the GIL from Python. This PEP has been accepted into Python 3.13 and is starting out as a compile-time flag for the building of the interpreter.
02:13 People compiling the Python interpreter are able to create two distinct versions, one with and one without the GIL. At the time of this recording, Python 3.13 is in the release candidate stage and folks out there have already released no-GIL playgrounds.
02:29 This is still experimental and the main interpreter will still have the GIL for the foreseeable future.
02:35 Whether an interpreter is GIL or no-GIL will be available as a flag in the interpreter do extensions can query the state and change their behavior if they desire.
02:46 The long-term plan is that the GIL should go away. This is likely to be 2029 or 2030, it’s still a way off. But like with the Gilectomy, the team
02:57 reserves the right to change its mind. If the end result has similar problems to the Gilectomy, this branch may also get pruned. It’s still early enough that conversations about what will and what will not be backwardly compatible are ongoing.
03:12 Even if the GIL doesn’t go away completely, there is work happening to optimize it. One such piece of work has to do with subinterpreters. Subinterpreters are distinct Python interpreters within the main process.
03:25 The analogy here are threads are to processes as subinterpreters are to the root interpreter. And my analogy holds in that subinterpreters are able to share some state.
03:36 These things have actually been around for a long time, but prior to Python 3.12, they were used by extensions and not available in the language itself. Python 3.12 did some work on subinterpreters, including moving the GIL into them.
03:51 That means further localization of the lock and makes the global part slightly less global all without breaking backward compatibility.
04:00 C extensions have to explicitly declare that they want to run in this mode, and otherwise they get the default. New extensions that want to take advantage of this feature can, while older ones don’t have to break.
04:11 Python 3.13 further improves on this by exposing some of these mechanics at the language level in the hope that Python code itself can take advantage of this feature down the road.
04:22 And there you have it, the GIL in all its present and possibly lack of a future glory. Last up, I’ll summarize the course and point you at other sources of information.
Become a Member to join the conversation.