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: "Corey O'Connor" <email@hidden>
- Date: Wed, 24 Jan 2007 11:56:44 -0800
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? 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 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...). 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.
Thanks!
--
-Corey O'Connor
_______________________________________________
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