• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?


  • Subject: Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
  • From: JongAm Park <email@hidden>
  • Date: Wed, 14 Mar 2012 13:18:46 -0700

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<email@hidden>  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 (email@hidden)

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:

This email sent to email@hidden

References: 
 >[Q] Why is the threading and UI updating designed to be done only on a main thread? (From: JongAm Park <email@hidden>)
 >Re: [Q] Why is the threading and UI updating designed to be done only on a main thread? (From: "Gary L. Wade" <email@hidden>)

  • Prev by Date: Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
  • Next by Date: Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
  • Previous by thread: Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
  • Next by thread: NSTextField not consuming keyDown events; How do I prevent super view from receiving those events?
  • Index(es):
    • Date
    • Thread