Re: Coreaudio-api Digest, Vol 3, Issue 66
Re: Coreaudio-api Digest, Vol 3, Issue 66
- Subject: Re: Coreaudio-api Digest, Vol 3, Issue 66
- From: Christopher Ashworth <email@hidden>
- Date: Tue, 28 Feb 2006 21:56:40 -0500
In Objective-C there is the following method:
- (void)performSelectorOnMainThread:(SEL)aSelector withObject:(id)arg
waitUntilDone:(BOOL)wait
I'm not sure if this suffers from a similar problem to the one with
CFMessagePorts.
Are you certain you need to send the message directly from your
render thread? What about saving the time information and allowing a
separate polling thread to update your widget at some interval? This
would decouple the update of your widget from the render thread in
order to allow the updates to happen in whatever manner was both
sufficient, efficient, and adjustable, rather than always being stuck
updating with great frequency in the render thread.
On Feb 28, 2006, at 2:33 PM, email@hidden
wrote:
Date: Tue, 28 Feb 2006 10:49:18 -0700
From: Wayne Anderson <email@hidden>
Subject: Run Loops and CFMessagePorts
To: Core Audio <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
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.
_______________________________________________
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