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
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
