[PyKDE] Fatal Python error: PyEval_RestoreThread: NULL tstate

[Patrick Stinson]

This a great recipe for thread-communication.

Unfortunately, 
my problem lies more between C threads and the main python thread. First off, 
I'm not using any Qthread objects. Since the audio streaming requires its own 
thread, I started out using regular pthreads directly in the C code. After 
getting the below error for no explainable reason, I decided since python was 
complaining, I'd try orignating the threads in python by starting a few 
(audio/buffering) threads that just ran the appropriate thread in the C++ 
lib. The threads wouldn't die until a specific C++ routine was called to 
cause them to finish, execution would pass back into python space, and the 
py-threads would die. Everything worked fine with that.

Now that I've been using that method for a while, I feel comfortable enough to 
try to push the threads back into the C++ lib. Because those threads are 
considered real-time capable, they never enter python code, so not using 
python to start them seems reasonable. 

Now, back to my original question, in a pythin extension module that requires 
the use of threads, what is the smartest way to do such a thing? I appreciate 
the value of seperating the threads as much as possible, and that I have 
done, but what for the tstate problem? Why is that even an issue if the code 
never reaches python?


On Thursday 11 December 2003 14:32, Myddrin wrote:
> On Wednesday 10 December 2003 5:24 pm, Patrick Stinson wrote:
> > In coding an audio library that requires the use of different threads
> > (audio streaming, disk buffering, application), I've run into similar
> > unexplainable (to me) fatal python errors involving the useage of the C
> > Python API. the python interpreter spits out
> >
> > Fatal Python error: PyEval_RestoreThread: NULL tstate
>
> I've encountered the same.  If you take a look (carefully) at the PyQT docs
> on riverbank you'll see a brief set of rules.  What it boils down to is the
> more seperated you can keep your QT calls from non-QT threads, the better. 
> I've also seen random freezes and so forth if you aren't extremely careful.
>
> Personaly, I've found that useing a python Queue object to bridge the gap
> between a python queue and a QThread works well.  Then you just use
> postEvent to send the message on to your UI thread.  We've put in a couple
> hundred hours of testing on this solution and it seems to work well.  (And
> not nearly as slowly as you would think!)
>
> Cheezy ASCII are warning (May not look good in some email clients, sorry):
> C Thread			Queue			QThread
> -----------------------------------------------------------------
> 								Does blocking get on Queue
>
>
>
> C Thread puts ---------->Queue  --------------->Get value
> value on to Q 		 passes 			|
> 				to QThread			|
> 								Create QCustomEvent
>
>
> 								Post Event
>
>
> 								Loop back.
>
>
>
> _______________________________________________
> PyKDE mailing list    PyKDE at mats.imk.fraunhofer.de
> http://mats.imk.fraunhofer.de/mailman/listinfo/pykde