Multithreaded C API Python questions

robert no-spam at no-spam-no-spam.invalid
Thu Nov 9 14:22:40 CET 2006

Svein Seldal wrote:
> Hi
> A couple of mulithreaded C API python questions:
> I) The PyGILState_Ensure() simply ensures python api call ability, it 
> doesnt actually lock the GIL, right?
>      PyGILState_STATE gstate;
>     gstate = PyGILState_Ensure();
> II) Am I required to lock the GIL prior to running any python functions 
> (in a threaded app)?
>     PyThreadState *pts = PyGILState_GetThisThreadState();
>     PyEval_AcquireThread(pts);
>     PyObject_CallObject(...);
> III) Shouldn't the GIL be released after 100 bytecodes or so to enable 
> other waiting threads to get the GIL?
> I'm unable to get access to python as long as another python call is 
> executing. The PyEval_AcquireThread() call blocks until the first call 
> returns. I was hoping that the python system itself would release the 
> GIL after some execution, but it itsnt.
> I am dependent upon the ability to have to threads executing in python 
> land at the same time. How can this be done?

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

PyObject_CallObject(...)     calls Python code. Thus the interpreter will switch and do as usuall during that.

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)


More information about the Python-list mailing list