Franco DiRosa <[EMAIL PROTECTED]> added the comment: Thanks Adam
but.... I'm still confused because... There is a new rule in version 2.3.5. Which is one interpreter with many thread states are supported for the GIL functions. So this code breaks that rule since this if statement is checking if the interpreters are different for the current GIL state and the new ts which it can't be (i.e. unsupported). See this email that points to the python documentation for 2.3.5 regarding this "new" rule... http://mail.python.org/pipermail/python-dev/2005-May/053840.html Here is the extract of the email pertaining to this issue... 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. So regardless if we use the GIL functions or the lower level functions it all eventually boils down to this Swap function which has this condition that doesn't match what the documentation is stating. So which way is it? Can't have it both ways. It seems since 2.3.5 they don't want you to use multiple interpreters is my guess when threading is involved. _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1758146> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com