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

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.

Cheers, Nick.

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

More information about the Python-Dev mailing list