Franco DiRosa [EMAIL PROTECTED] added the comment:
Also, that Py_DEBUG check effectively says that if you use simplified
GIL API for a particular thread against the first interpreter, you are
prohibited from creating additional thread states for that thread.
I found that you cannot create
Franco DiRosa [EMAIL PROTECTED] added the comment:
By the way. I switched to using the GIL functions on the main
interpreter and everything works great now. It is a better solution to
use the GIL functions because I also had my own code that prevented
dead lock from occuring when a python
Franco DiRosa [EMAIL PROTECTED] added the comment:
OK,
I think I found my problem. I was using the main interpreter state
(the one created by Py_Initialize) to create new thread states with.
It seems that this interpreter state is reserved for GIL functions so
one will need to create a new
Franco DiRosa [EMAIL PROTECTED] added the comment:
I believe PyThreadState_Swap function in ceval.c has a bug as I stated
earlier. However, I have not seen it included in the latest patches so
now I wonder...
The following line in PyThreadState_Swap...
if (check check-interp == newts-interp
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
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
Franco DiRosa [EMAIL PROTECTED] added the comment:
The documentation states that thread states are supported within a
single interpreter and not supported across other interpreters
(specifically for the GIL functions which are just wrapper functions
around the PyEval_ functions).
So I would
