Multithreaded C API Python questions
robert
no-spam at no-spam-no-spam.invalid
Thu Nov 9 08:22:40 EST 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)
-robert
More information about the Python-list
mailing list