Multithreaded C API Python questions

[Svein Seldal]

robert wrote:
> PyGILState_Ensure/Release guarantees to establish the GIL - even if it 
> was already held (useful if you deal with complex call 
> ordering/dependencies)

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 
consuming process.

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.


Svein