[PyKDE] PyThreadState_Get, PyEval_*Thread, NULL tstate.

[Patrick Stinson]

On Friday 13 February 2004 10:53, Phil Thompson wrote:
> On Thursday 12 February 2004 20:48, Patrick Stinson wrote:
> > I posted a while ago about the 'PyEval_RestoreThread: NULL tstate:'
> > error, and now I'm getting the same problem with PyThreadState_Get (if I
> > remember correctly, its the call that happens before
> > PyEval_RestoreThread).
> >
> > urls:
> > http://www.mail-archive.com/pykde%40mats.imk.fraunhofer.de/msg01437.html
> > http://mats.imk.fraunhofer.de/pipermail/pykde/2003-December/006798.html
> > and even earlier:
> > http://www.mail-archive.com/pykde%40mats.imk.fraunhofer.de/msg01437.html
> >
> > As Before, I'm writing an audio application that uses background threads
> > for buffering and audio streaming. The threads are entirely contained in
> > my c++ (sipped) lib and execution never enters python code. What could
> > cause a NULL thread state in the interpreter? This occurs at different
> > times, and with what seem slike varying levels of complexity in pyqt Gui
> > code. Does anyone know how I should be interpreting this? What does this
> > generally mean?
>
> I can't remember which version of SIP you are using.
>
> If you are using SIP v3 then you have to be *extremely* careful about
> managing the thread state.  Are you sure that "execution never enters
> python code"?
>
> Things are much easier with SIP v4 because it uses the new thread API in
> Python 2.3.
>
> Phil


I will check harder for spots where it might. Currently I am using sip and 
PyQt 3.8, because of the odd problem I was having with threads appearing to 
'lock up'. How is it that I can 'manage' the thread state at the python 
level? Do you mean I should be careful how my py-objects are used by 
different python threads, as the interpreter is not considered thread-safe?