• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Things not to do in a thread (was Re: Leak while in Midi thread)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Things not to do in a thread (was Re: Leak while in Midi thread)


  • Subject: Re: Things not to do in a thread (was Re: Leak while in Midi thread)
  • From: Jeff Moore <email@hidden>
  • Date: Sun, 12 Jan 2003 17:45:45 -0800

There really isn't anything the HAL or the MIDI server can do to enforce any sort of discipline on the code that executes inside of the callbacks. They can pretty much do what they want.

At no time will the HAL stop an IOProc without a call to AudioDeviceStop. But, the HAL will notice if you take too much time inside of your IOProc and issue a kAudioDevicePropertyOverload notification as well as force a full time out period while the HAL resynchs with the hardware.

On Saturday, January 11, 2003, at 03:19 PM, Andrew Kimpton wrote:

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-)




--

Jeff Moore
Core Audio
Apple
_______________________________________________
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.

References: 
 >Things not to do in a thread (was Re: Leak while in Midi thread) (From: Andrew Kimpton <email@hidden>)

  • Prev by Date: Re: Sample AUs not registering
  • Next by Date: Erm... what's 'midiecho'?
  • Previous by thread: Things not to do in a thread (was Re: Leak while in Midi thread)
  • Next by thread: Re: Leak while in Midi thread
  • Index(es):
    • Date
    • Thread