[Python-3000] the future of the GIL (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Tue May 8 21:25:15 CEST 2007

Wouldn't multiple interpreters (assuming the problems with them would be fixed) in the same process give the same benefit? A separate GIL for each one?

No. There is a global "current thread" variable that is protected by the GIL (namely, _PyThreadState_Current). Without that, you would not even know what the current interpreter is, so fixing all the other problems with multiple interpreters won't help. You could try to save the current thread reference into TLS, but, depending on the platform, that may be expensive to access.

The "right" way would be to pass the current interpreter to all API functions, the way Tcl does it. Indeed, Tcl's threading model is that you have one interpreter per thread, and don't need any locking at all (but you can't have multi-threaded Tcl scripts under that model).

However, even if you give multiple interpreters separate GILs, you still won't see a speed-up on a multi-processor system if you have a multi-threaded Python script: once one thread blocks on that interpreter's GIL, that thread is also "wasted" for all other interpreters, since the thread is hanging waiting for the GIL. To fix that, you would also have to use separate threads for the separate interpreters. When you do so, you might just as well start separate OS processes.

Regards, Martin

More information about the Python-3000 mailing list