Yes. I agree. That is one of the approach I'm thinking of when I handled
similar issue with QuickTime.
Thanks,
On 3/14/2012 10:05 AM, Gary L. Wade wrote:
On Mar 13, 2012, at 2:09 PM, JongAm Park<jongamp...@sbcglobal.net> wrote:
In other words, the thread function may want to update UI like inserting a log message to
a text field on a window and thus asking main thread to do so, and main thread is waiting
to acquire a lock or waiting using "Join", then either the main thread and the
other thread can't progress.
To solve your thinking on this matter, conceptualize the background thread as a
(M)odel object, the main thread a (V)iew object, and possibly an NSMutableArray
of NSStrings each having an individual log message being a (C)ontroller object.
By breaking your logic up accordingly, it should be more obvious why things are
the way they are. A simple way to update the UI is to add a timer to your main
thread that checks to see if the controller object has been changed; if so, it
can update the UI. To accommodate a full UI thread and fit within a user's
visual update time, a time interval of 1/120 second should be fine. Naturally,
you'll want to lock the controller object while being updated by the model or
being (quickly) read by the view.
You don't want your background thread wasting time waiting on the user to see
its data; let it keep working and let the main thread check for updates when it
can.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
