Questions on the C Thread API

[Phil Thompson]

Duncan Booth wrote:
> 
> Phil Thompson <phil at river-bank.demon.co.uk> wrote in
> news:mailman.1018871909.16619.python-list at python.org:
> 
> > Currently, any C++ method that might block effectively has a call to
> > PyEval_SaveThread() before it and a call to PyEval_ReleaseThread() after
> > it. Any C++ virtual method that has been re-implemented in Python first
> > checks to see if it already has the global lock, and acquires it if it
> > doesn't. The Python method is then evaluated, and the global lock
> > released if it had previously been acquired. The check if the lock has
> > already been acquired is necessary because I only release the lock on a
> > small subset of C++ methods, ie. those that might block, which I do for
> > reasons of efficiency.
> 
> PyEval_SaveThread and PyEval_ReleaseThread both release the
> interpreter lock. Did you mean PyEval_RestoreThread for the second one of
> these?

Yes I did.

> Anyway, when you are going to do something that might block you save the
> thread state and restore it later. I presume you save the state in some
> thread local storage because you could have several threads all suspended
> in this way.
> >
> > All the above works fine, so long as all the C++ calls are made from the
> > same thread. With the support of the Qt thread classes, that assumption
> > is no longer valid.
> >
> > Therefore, just before calling the Python code that re-implements a C++
> > virtual method, the global lock has to be acquired, and the correct
> > thread state restored. However, to prevent a deadlock the thread state
> > can only be restored if it is not the current one, but there is no way
> > to get the value of the current thread state without having acquired the
> > global lock. Catch 22.
> 
> Get the saved thread state for the current thread. If you don't have one
> then by definition you already have the global lock. If you have one then
> call PyEval_RestoreThread to get the lock and set the state and clear your
> saved state to NULL. Remember whether or not you had a thread state around
> the callback and only save the state/release the lock if you previously
> restored a state.

This is the bit I don't understand. How can I get the saved thread state
for the current thread? Do you mean I can use the Python API to get it
(in which case I get back to Catch 22)? Or do you mean I have to write
code that determines by other means what the current thread is and then
get the corresponding Python thread state?

Phil