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