| > Removing the GIL sounds like it will make typical Python programs slower and will introduce a lot of complexity? There is a lot of Python code that either explicitly (or implicitly) relies on the GIL for correctness in multithreaded programs. I myself have even written such code, explicitly relying on the GIL as synchronization primitive. Removing the GIL will break that code in subtle and difficult to track down ways. The good news is that a large percentage of this code will stay running on older versions of python (2.7 even) and so will always have a GIL around. Some of it however will end up running on no-GIL python and I don't envy the developers who will be tasked tracking down the bugs - but probably they will run on modern versions of python using --with-gil or whatever other flag is provided to enable the GIL. The benefit to the rest of the world then is that future programs will be able to take advantage of multiple cores with shared memory, without needing to jump through the hoops of multi-process Python. Python has been feeling the pain of the GIL in this area for many years already, and removing the GIL will make Python more viable for a whole host of applications. |