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

Paul Moore p.f.moore at gmail.com
Fri Dec 19 00🔞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 modpython) 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