Franco DiRosa <[EMAIL PROTECTED]> added the comment:
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)
_______________________________________
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
