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

Paul Moore p.f.moore at gmail.com
Fri Dec 19 00:18:07 CET 2008


2008/12/18 Greg Ewing <greg.ewing at canterbury.ac.nz>:
> 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.
>
>> AIUI,
>> certain software (for example mod_python) has been using multiple
>> interpreters for a long while now
>
> Multiple interpeters are possible, they're just not completely
> independent. Whether this is a problem depends on the reason
> you want multiple interpreters. In the Apache case, it's
> probably more about providing virtual Python environments than
> free-threading between interpreters.

OK, but how close is it to providing isolation for threads running
under the control of the GIL? I'm thinking of something along the
lines of an in-process version of fork(), which spawns a new
interpreter and runs the 2 interpreters as threads, still using the
GIL to enforce serialisation, but otherwise independent. I believe
that Perl uses this model for its "interpreter threads"
implementation.

Paul.


More information about the Python-Dev mailing list