• 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: What is causing this deadlock?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What is causing this deadlock?


  • Subject: Re: What is causing this deadlock?
  • From: Bob Stuller <email@hidden>
  • Date: Wed, 30 Jan 2008 10:35:49 -0500

Jeff, Greetings!

At 12:24 PM -0800 1/28/08, Jeff Moore wrote:
Sorry this took so long. At any rate, enough info made it through that I got a good sense of what's going on.

Well, thank you so much for getting back to me: News I Can Use.

The first thing I want to say is that you should file this in Radar. This appears to be a deadlock in the HAL that I'd like to look at a bit closer.

My pleasure. Thanks for looking at this. #5714837

That said, my first thought would be to ask why are you are using hog mode in the first place? Most apps that think they need hog mode, don't really need it at all. Judging from the name of your app (MacSpeech Dictate Medical), it doesn't seem to me that your app would need to use hog mode for anything.

While our needs are in fact modest, they are also very specific. At this point in time we grab hog mode only on devices without output, only while actively acquiring audio, setting up everything on the spot. For the average user, it feels like the way to go, giving their dictation program exclusive access to audio input. But I may be missing something.


I guess it concerns me that another process could change the input device out from under us & that other process could even itself grab hog mode & we'd, minimum, lose some audio while reconfiguring.

My second thought is that it appears that you've pointed the HAL at your main thread to use for notifications. It turns out that having Cocoa and the HAL share this thread is not a good idea. Cocoa can monopolize that thread way too easily to make it useful as the HAL's notification thread. Cocoa apps should really just let the HAL manage it's own notification thread. It's possible that this may clear up this deadlock, but it may just move it to being between the notification thread and your worker thread that is releasing [grabbing -Ed.] hog mode.
... which would be a better place for it.  B-)

I notice that HALLab is using the main thread. Anything that I need to look out for? I mean, other than perhaps having to grab hog mode on this otherwise dedicated thread?

Peace,
Bob
--

One measurement is worth a thousand guesses.
	- Anonymous
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: What is causing this deadlock?
      • From: Jeff Moore <email@hidden>
References: 
 >Re: What is causing this deadlock? (From: Bob Stuller <email@hidden>)
 >Re: What is causing this deadlock? (From: Jeff Moore <email@hidden>)

  • Prev by Date: Re: AU's new prioritized MIDI specification
  • Next by Date: Re: AU's new prioritized MIDI specification
  • Previous by thread: Re: What is causing this deadlock?
  • Next by thread: Re: What is causing this deadlock?
  • Index(es):
    • Date
    • Thread