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 12:02:44 -0800
On 1/24/07, Stephen Davis <email@hidden> wrote:
By default, signal()/kill() sends a "global" signal to the app and it is not entirely clear (to me) which thread ends up catching it. However, if the signal is sent with pthread_kill() specifically to the main thread, then maybe this _should_ work. However, if the runtime is using pthread_kill( pthread_self(), ...) then the IO proc is not set up to ignore the signal and the app will terminate. Regardless, doing such shenanigans in the IO proc thread is REALLY not a good idea.
Yea.. I'm highly suspect of Haskell's runtime system in this case. They have "virtual" threads and "OS" threads which, IMO, is a distinction that should be enforced on the users of Haskell. Anyways, Haskell is supposed to have a working, concurrency capable runtime system. I've been assured that the system functions as expected when used from multiple pthreads, but I don't think anyone has tried a realtime thread setup like Core Audio's.
If you want to continue using Haskell as your language of choice, you might consider running the IOProc in C/C++/maybe ObjC and just pulling the audio data from a buffer generated by a separate thread running your Haskell code.
Good idea. 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