[Python-3000] the future of the GIL

["Martin v. Löwis"]

> 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