Re: Does CoreAudio use the alarm signal in the IO proc thread?
Re: Does CoreAudio use the alarm signal in the IO proc thread?
- Subject: Re: Does CoreAudio use the alarm signal in the IO proc thread?
- From: Jeff Moore <email@hidden>
- Date: Wed, 24 Jan 2007 12:13:07 -0800
On Jan 24, 2007, at 11:56 AM, Corey O'Connor wrote:
On 1/24/07, Jeff Moore <email@hidden> wrote:
I'm pretty sure that signals are treated specially by the kernel and
are not based on Mach message passing.
One other thing that occurred to me is that the signal thing may be a
red herring. The real problem may be that some of the constructs that
Haskell is using in it's run time might not work correctly on a real
time thread, which has special properties, like being of a very high,
non-degrading priority. It would be easy enough to test as you can
create a test program that spawns a real time thread that can make
calls back into the Haskell run time.
Is there a primer that notes the caveats of using real time threads?
That's a good question. The API you call to turn a thread into a real
time thread is a Mach API, though, so it might be described in the
Mach docs.
I'd presume the execution time of code in a real time thread is
constrained, but beyond that is there anything else I should be
aware of?
The non-degrading priority of the thread means that spin locks and the
like are not going to work like you'd expect. The fact that it's a
really high priority thread can create priority inversions pretty
easily.
Finally, in the HAL's case, an IOProc should try extra hard to not
block the thread. This generally means that locking mutexes and what
not needs to be avoided.
The test you describe seams like a good next step for debugging this
problem. I started on this but I got distractd by my real job (shame
really...).
You might find the class, CAPThread, in the PublicUtility folder of
our SDK useful. It provides a C++ wrapper around the various APIs you
have to call to spawn threads and muck around with their priority and
scheduling policy. At the very least, it will show you what API calls
are involved.
I do have some question about the Core Audio thread:
- I presume the thread is using pthread's real time capabilities?
Not some mach/os x specific functionality?
- Is it round-robin or FIFO?
I suppose I could find out by introspecting the thread actually, but
if you know off the top of your head that'd be helpful.
It's neither. The scheduling policy is called the time constraint
policy. The HAL calls Mach APIs to assign this policy and to set the
constraints for a thread. In fact, it uses the CAPThread C++ class I
mentioned above.
--
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