Things not to do in a thread (was Re: Leak while in Midi thread)
Things not to do in a thread (was Re: Leak while in Midi thread)
- Subject: Things not to do in a thread (was Re: Leak while in Midi thread)
- From: Andrew Kimpton <email@hidden>
- Date: Sat, 11 Jan 2003 15:19:36 -0800
Jeff Moore wrote:
Threads like those used for MIDI callbacks and for the HAL's IO cycle
are more functionally equivalent to hardware interrupts than to normal
user threads and really need to be treated as such. Just because you
can call malloc() anytime, anywhere doesn't mean that you should.
<snip>
Also, you need to avoid doing things that might block the thread (the
HAL is especially sensitive to this) like locking a mutex. Further,
you have to avoid constructs like spin locks that rely on thread
priorities degrading when the thread becomes CPU bound (a spin lock in
a time constraint thread is the easiest way to lock your system up).
Does the HAL do anything to 'enforce' timely behaviour in the callback
functions ? Or attempt to deal with bad situations ? I ask because a
relatively simply application I have seems to simply 'stop' a random
points in the playback - essentially it looks like the HAL has stopped
calling the callback function for the Default Output Audio Unit. (I can
tell this since another thread in my app is waiting to acquire the
semaphore released by the callback function).
Since I AM acquiring a semaphore in the HAL callback (which looks like a
bad idea according to the above paragraphs) I wonder if the HAL is
electing to stop calling my callback since I took 'too long' on a
previous call ?
Andrew 8-)
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.