[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.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
More information about the Python-Dev
mailing list