homepage

I'm unsure if you are understanding what I'm doing so here is the 
story...
I stepped through Py_Initialize and this function takes the main 
interpreter and it's initial thread state and makes that the GIL thread 
state.
The following code in Py_Initialize hijacks the main interpreter and 
thread state for GIL use...
/* auto-thread-state API, if available */
#ifdef WITH_THREAD
 _PyGILState_Init(interp, tstate);
#endif /* WITH_THREAD */
WITH_THREAD is defined since I'm using multithreading in my application.
So now if you create thread states from the main interpeter and use the 
PyEval_Acquire/Release and PyThreadState_Swap you will get the 
assertion when compiled with the DEBUG option. If you use the 
PyGILState_Ensure and PyGILState_Release functions you don't. 
What I'm doing is that I have a Windows application with embedded 
python. The application spawns multiple threads each running a python 
script. Each application thread has its own unique PyThreadState 
created from the main interpreter because I wanted all the modules 
loaded only once for resource conservation purposes (thus use only one 
interpreter). I used PyEval_Acquire/Release and PyThreadState_Swap to 
handle swapping in each application thread's thread state when each one 
uses the python API. This worked great in RELEASE compilation but in 
DEBUG it asserted. Now that I use the GIL functions it works well and 
not only that, I removed the code I had put in myself to handle python 
callback's into the application and avoiding deadlocks by calling 
PyEval_Acquire onto itself (since it uses mutexes which doesn't do 
reference counting so it could deadlock waiting on itself to complete)