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