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 10:47:32 -0800
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.
On Jan 23, 2007, at 7:23 PM, Herbie Robinson wrote:
At 1:59 PM -0800 1/23/07, Corey O'Connor wrote:
I'm trying to figure out why I cannot use Haskell from a CoreAudio
HAL IO proc. One thing Haskell does, which is questionable IMO, is
use the alarm signal for it's own thread scheduler. The program is
behaving as if the Haskell code is terminating early, but only in
the HAL IO proc thread. I think this would be consistent with the
Haskell code triggering a signal but instead of the Haskell
scheduler recieving the signal another signal handler is triggered.
Is it possible that CoreAudio registers it's own signal handler in
the IO proc thread? Or are there other caveats to the CoreAudio
realtime thread that would account for this behavior?
Signals aren't a native thing for MACH, right?
That would mean they are probably implemented with message passing
and something context dependent to catch the messages...
--
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