Multithreaded C API Python questions
svein at seldal dot com
Thu Nov 9 14:44:25 CET 2006
> PyGILState_Ensure/Release guarantees to establish the GIL - even if it
> was already held (useful if you deal with complex call
I understand this to mean that I dont need to explicitly lock the GIL
(with PyEval_AcquireLock() or PyEval_AcquireThread()).
Well I cant figure out the PyGILState_Ensure() because if I only use
this function to establish the GIL, when calling python, python will
shortly after crash with "Fatal Python error: ceval: tstate mix-up".
This happens consistently when the main app and the extra thread has
called python and both are busy executing python code.
> PyObject_CallObject(...) calls Python code. Thus the interpreter
> will switch and do as usuall during that.
BTW What do you mean by switch?
> In your/C/system... code you are responsible to release the GIL or not
> to enable other Python threads (and prevent from deadlocks) Usually
> you'd do this * if you do time consuming C/system stuff
> * or if the code can possibly renter Python through the system (e.g.
> when you call a Windows function which itself can create Windows
> messages to be routed back into Python message handlers)
The main problem is that not done this way, it's the other way around.
My main C app will call a python function which will be a lengthy time
The main C app will call python and it will never return from
PyObject_CallObject(...), while the extra thread should call a py
function to deliver occational messages into C.
More information about the Python-list