Re: What is causing this deadlock?
Re: What is causing this deadlock?
- Subject: Re: What is causing this deadlock?
- From: Jeff Moore <email@hidden>
- Date: Wed, 30 Jan 2008 11:18:55 -0800
On Jan 30, 2008, at 7:35 AM, Bob Stuller wrote:
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.
The audio system in Mac OS X has been set up so that sharing the audio
device is the normal mode of operation. A large part of that is that
the settings belong to the user. Apps should not be making adjustments
to them. Besides by taking hog mode, your app is denying the use of
that device to other apps on the system which also goes against the
nature of sharing in the audio system.
So, I couldn't disagree more with your usage of hog mode. Your app has
no idea what else might be going on on the system. The right thing to
do is to make your app more flexible in how it handles the input
device. It should be able to adapt to changes dynamically. Besides,
there are devices that can't be hogged (like aggregate devices), and
if your app isn't already flexible enough to handle that, you are
going to be in trouble down the road.
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?
I don't think your app should be using hog mode at all. But that's
really beside the point I was trying to make which was that you should
let the HAL run it's own notification thread in a Cocoa app. The
reason why is that the normal event handling in Cocoa can leave the
HAL's run loop sources starved for time on that thread. HALLab was
written before we figured this out and so is a little out of date on
this issue.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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