[Python-Dev] Multiple interpreters not compatible with current thread module

[Jeremy Maxfield]

The current threadmodule.c does not seem to correctly support multiple
(sub) interpreters.

This became apparent when using jep - (a Java/Python bridge) and also
seems to cause problems with mod_python.

The incompatibility began in Python version 2.3.5 and has been traced to changes
to the 2.4 threadmodule.c that were backported to the 2.3 delivery.
A bug report was raised on 2005-03-15
(http://sourceforge.net/tracker/index.php?func=detail&aid=1163563&group_id=5470&atid=105470)
which covers the problem in more detail.

I've just submitted a patch (I hope it's correctly formatted)  for
threadmodule.c
(http://sourceforge.net/tracker/index.php?func=detail&aid=1203393&group_id=5470&atid=305470)
adapted from the pre-2.3.5 threadmodule.c (replacing the
PyGILState_XXX calls with those from the earlier thread module).
The patch works correctly but it will probably re-introduce the
problem that the change for threadmodule.c version 2.59 fixed.("Fix
for [ 1010677 ] thread Module Breaks PyGILState_Ensure(),and a test
case.When booting a new thread, use the PyGILState API to manage the
GIL.").
The documentation (http://docs.python.org/api/threads.html) states
"Note that the PyGILState_*() functions assume there is only one
global interpreter (created automatically by Py_Initialize()). Python
still supports the creation of additional interpreters (using
Py_NewInterpreter()), but mixing multiple interpreters and the
PyGILState_*() API is unsupported. ", so it looks like that using the
PyGilState_XXX functions in the core threadmodule.c means the
Py_NewInterpreter() call (i.e. multiple interpreters) is no longer
supported when threads are involved.

This problem is preventing us upgrading to Python 2.4 so we'd
obviously like to see  a resolution the next Python release if that
were possible...

Cheers,
Max