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 -- http://mail.python.org/mailman/listinfo/python-list
