Multithreaded C API Python questions

robert no-spam at no-spam-no-spam.invalid
Fri Nov 17 07:01:34 EST 2006


Svein Seldal wrote:

> A real beauty about the PyGILState_Ensure() is the fact that if it's 
> called from a thread that is (yet) unknown to python, it will actually 
> create the thread state object for you (with PyThreadState_New) and 
> acquire the lock. Hence, I dont have to worry about the process of 
> swapping thread states with PyEval_xxxThread() functions. I ONLY need to 
> use PyGILState_Ensure() prior to any py-ops.

Interesting - the PyGILState_Ensure was new to py2.3. I didn't notice so far, that it will even auto-create a fresh tread state (from default InterpreterState only). From the docs its not that clear. 

The confusion in usage is that one has to do 

Py_Initialize()
PyEval_InitThreads()
ts=PyEval_SaveThread()

in order to start clean for further pure "meta-high-level" PyGILState_Ensure/Release.

They obviously meant PyGILState_Ensure to make live easier, but the discussion shows, it adds additional worries probably forcing each user into investigating the Python C-code :-)

There should probably a extra init function for this meta-high-level usage like ..

PyGILState_PyInitThreads()   //  which would not pre-acquire the lock! - as anyone expects to enter then with PyGILState_Ensure

. and these 3 Functions grouped together in the docs for an easy-to-use meta-high-level thread state API.

The current thread state API doc, as you read it from top to bottom now, is in fact totally confusing for anyone who didn't develop Python himself :-)


Robert



More information about the Python-list mailing list