Re: Run Loops and CFMessagePorts
Re: Run Loops and CFMessagePorts
- Subject: Re: Run Loops and CFMessagePorts
- From: Doug Wyatt <email@hidden>
- Date: Tue, 28 Feb 2006 12:44:30 -0800
On Feb 28, 2006, at 9:49, Wayne Anderson wrote:
Hi All,
Sorry for the duplicate question, but I thought I would post this
under its own topic.
What is the preferred way to get a signal into the main thread run
loop from another thread within an application?
Say for example, I want to use the time stamp from the CA render
thread and signal the app thread to update some widget.
From the discussion under another subject line (interapplication
midi communication, cfmessageports, ques) it looks like using
CFMessagePorts could cause priority inversion problems because it
allocates memory to send a message.
Any suggestions or additional insight on this question would be
greatly appreciated.
If it weren't the main thread you wanted to signal, I'd suggest a
pthread condition. But the only way to send a message to an app's
main thread is with a CFRunLoop source.
The two ways I've done this are:
- CFRunLoop timers (or NSTimer).
- sending Mach messages to a CFMachPort.
CFMessagePort might not take a lock if you don't send any data; I'll
have to research this.
NSThread's performSelectorOnMainThread may be useful if you're in
Cocoa. I'm not sure if this is lock-free however.
If you send Mach messages via CFMessagePort or directly using Mach,
you'll want to avoid sending a lot of messages, or you can block on
the sending side.
Depending on what you're doing, it may be simplest to run a
continuous timer on the main thread and poll the conditions you want
to monitor.
--
Doug Wyatt
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