31 Mar
2004
31 Mar
'04
1:20 p.m.
On Wed, 31 Mar 2004 12:24:31 +0200, Jens M Andreasen
<jens.andreasen(a)chello.se> wrote:
On ons, 2004-03-31 at 11:02, Jens M Andreasen wrote:
> So go for autonomous threads. Your code will be easier to read and
> maintain, and therefore also more likely to be correct.
>
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.
Just for the record. You probably already know this
...
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.
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.
Arve