Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
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:08:13 -0700
On 3/14/2012 9:19 AM, Wade Tregaskis wrote:
Threads themselves are very useful; multiple threads taking user input and updating the display to the user are not really useful, and the request for them more often than not betrays a lack of understanding of threading.
So you think it'd be great it every GUI app shared the same serial queue for all interactivity and drawing? Boy do I have a Mac Classic to sell you...
The reality is of course more of a compromise. It's quite common to do drawing across multiple threads, though you still synchronise the final "blits" around a single thread (i.e. the main thread). Likewise even event handling is often effectively multi-threaded, because you dispatch from the main thread to a variety of tasks, queues or worker threads.
Having a UI framework that either offloads some of this for you can actually be very useful. It would also be closer to the user experience we're trying to portray - for example, that each document on an app is totally independent. Having all documents hang because one is having issues (Safari I'm looking at you, you evil bastard) completely breaks that illusion.
That's good point.
One of the reason in the 90's those were allowed was to achieve the goal
you are concerned about, I think.
From sometime in 2000's, it seems to me that philosophy behind language
design and framework design were changed to be like current model.
Because, as you said, there can be some situation where it is a lot
easier and better to allow accessing GUI widgets from any threads, we
can feel sorry about it, but if language and framework designers changed
their mind to design like how they are now, there should be a workaround
for this kind of case.
I guess that allowing it will make distributing work unit, i.e. in the
form of blocks or lamda functions, difficult because there will be many
issues. So, I understand that and as Mr. Alfke said, there did exist
some difficulties in multithreaded programming.
So, it is trade-off between two conflicting idea. Currently reducing
complexity of maintaining and architecting thread-based S/W architecture
looks to be the main virtue.
In the case of the Safari thing, if WebKit or Apple developers create
each window as processes rather than threads, they can reduce dependency
between "documents" or "windows" more than using threading, although
data sharing is still needed between processes.
I remember sometime during 1990's there were debate between process
model vs. thread model.
Usually Unix society preferred process model, because it is safer and
death of one software processing unit doesn't make the whole program
dies. However, somehow thread model which were more popular in PC world
got the popularity more. ( thanks to its light-weight? and.. for me, it
was due to less confusing model for threading. )
Whatever the history is, we need to find some workaround when we reach a
point where one model is not as great as others. :)
JongAm Park
_______________________________________________
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