[Python-Dev] The endless GIL debate: why not remove thread support instead?

Nick Coghlan ncoghlan at gmail.com
Fri Dec 19 00:05:17 CET 2008

Greg Ewing wrote:
> Paul Moore wrote:
>> Do you know if these remaining problems are listed anywhere?
> There was a big discussion about this in comp.lang.python
> not long ago. Basically all the built-in types and constants
> are shared between interpreters, which means you still need
> a GIL to stop different interpreters stepping on each other's
> toes.

That kind of thing is under the core's control though - the 2.x module
initialisation problem means that you can't write a multiple interpreter
friendly extension module even if you want to.

The new per-interpreter state mechanism could also be used internally by
the core to duplicate some of that global state for each new interpreter.

I see the introduction of the interpreter specific state mechanism as a
big step because it provides an underlying mechanism that makes the
problem solvable *in principle* through a combination of per-interpreter
state and finer grained shared locking, making it just a practical
implementation problem to see if that can be done without adversely
impacting single interpreter performance.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list