On ons, 2004-03-31 at 11:02, Jens M Andreasen wrote:The thing is I don't have complete control over the audio thread, a user defined callback is involved. In working on the ALSA implementation of the PortAudio library there has been a request for realtime scheduling of the audio thread, similar to the older OSS implementation. The OSS implementation starts both a watchdog and a canary thread; the watchdog will kill the audio thread (with SIGKILL) if it doesn't respond within 3-second intervals, or lower it's priority if the (normal priority) canary thread is starved.
So go for autonomous threads. Your code will be easier to read and maintain, and therefore also more likely to be correct.
Just for the record. You probably already know this ...I love the push/pop combination :] It leads to easy cleanup when the audio thread exits, I don't think this will be invoked however if I kill it with SIGKILL however. Maybe a user defined signal, where the thread will issue pthread_exit in the handling function? Either that or I could perhaps go for the asynchronous pthread_cancel, and use a different mechanism for requesting shutdown of the audio thread.
I forgot to mention the pthread_cleanup_push/pop pair which can make life somewhat easier when the reason for termination is not known at compile time.
This of course implies use of pthread_exit instead of return.
Last time I checked they were defined as macros, so gcc -Wall might bark at you when you are cascading several instances in the same function.
Arve
