[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Does CoreAudio use the alarm signal in the IO proc thread? Jeff Moore Wed Jan 24 18:00:25 2007

On Jan 24, 2007, at 11:56 AM, Corey O'Connor wrote:

On 1/24/07, Jeff Moore <[EMAIL PROTECTED]> 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

Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      ([EMAIL PROTECTED])
Help/Unsubscribe/Update your Subscription:

This email sent to [EMAIL PROTECTED]