The short answer is that: 1) Given our current languages and tools, parallel programming is hard. 2) For the moment, it is generally the case that one thread is enough to keep a UI updated and responding to events, thus avoiding #1. 3) When one thread isn't enough to keep a UI updated and responding to events, other threads can be used, and then the output of those threads can be fed to the UI thread.
On Tue, Mar 13, 2012 at 2:09 PM, JongAm Park <jongamp...@sbcglobal.net>wrote: > Hello, > > While doing projects with Cocoa and Objective-C, I have always thought > that allowing UI update only on main thread was a weak point of > Cocoa/Objective-C. > Especially, when gracefully terminating threads which would be better > update some UI stuff and if main thread is required to wait until those > threads finishes for clean exit, it can cause dead lock condition. > 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. > > But, I also noticed the same pattern with C# .NET. Unlike Win32/MFC and > like Objective-C/Cocoa, it also asks a main thread to update UI widgets. > > Is there any reason to design threading and UI update model like this? > At first I thought it was due to somehow Obj-C/Cocoa sticks to some old > model, but C# .NET is fairly new architecture. They could have avoided it > if doing so was better. So, I guess there must be some reason behind it. > > Can anyone explain the rationale behind it? > Also, is there a way to gracefully terminate an app by quitting threads > and main thread? > > Thanks, > JongAm Park > ______________________________**_________________ > > 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<http://lists.apple.com> > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/**mailman/options/cocoa-dev/** > brianlambert%40gmail.com<https://lists.apple.com/mailman/options/cocoa-dev/brianlambert%40gmail.com> > > This email sent to brianlamb...@gmail.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