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? _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
