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: Per Bull Holmen <email@hidden>
- Date: Wed, 14 Mar 2012 21:12:33 +0100
Den 20:00 14. mars 2012 skrev Wade Tregaskis <email@hidden> følgende:
> On the other hand, you could have an event handling framework which dispatched events to any of multiple threads/queues/whatever for you. For example, each window might have its own queue. This actually makes a lot more sense in many cases, as a default, since many actions within a single window/document are successive, not concurrent. If they are concurrent, you could then go to the trouble of manually dispatching things to other queues, or otherwise realising that concurrency.
I guess most seasoned Cocoa programmers are familiar with this
aproach, because they have probably not been doing everything in Cocoa
all their lives. It's just a matter of taste, really. I think it's
best to have it single threaded by default. I don't like the idea of a
multithreaded aproach by default, because as a general rule, you
should not make your application multithreaded unless you have a good
reason. So, it's just a matter of when do you want to do the extra
work? When you actually wanted to do it single threaded, but the
framework has a multithreaded approach by default, or the other way
around? Because each document or window is likely to need to access
shared data anyway. Also, whatever model comes with the framework is
likely to be not quite the best thing for your specific needs. I see
the point of not having one document obstruct the work of other docs,
but in many cases the best and easiest remedy to this might be to not
let any document block its thread at all.
Therefore, I think it's better that they focus their efforts on good
abstractions that make concurrent programming in general easier and
more efficient, like NSOperationQueue etc...
Per
_______________________________________________
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