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: Wade Tregaskis <email@hidden>
- Date: Thu, 15 Mar 2012 10:06:36 -0700
> While all these points are very good, I disagree with the conclusion
> because I believe in the wisdom: Keep simple things simple.
An argument for doing this in the frameworks is that it is then simpler to do this. No need for every developer to write the same boiler plate every time. And if it's in the frameworks, it'll force people to use it that wouldn't bother otherwise, which I'm arguing would be a fundamentally good thing. In the same way to forcing people to follow e.g. MVC entails lots of kicking and screaming initially, but is ultimately worth it.
Highly subjective, though, I recognise that. I think we've pretty much run this discussion to its end now, and it doesn't appear I've swayed you. That's okay.
> The one thing I do not understand is, how come you can't just
> implement the threading model that you find most productive for the
> task, on top of the core that receives events in the main thread? This
> can't be hard in most cases, and seems to fit better with the MVC
> approach in most cases: It is the views that receive events, and they
> do truly receive them sequentially. It is your models that may need to
> do things concurrently, not your views. If you need to draw from
> multiple threads, this can be done with the framework as it is.
Well, to be fair, there are a lot of people who think doing any real concurrency is hard, and as I noted they're the ones who would benefit most from the frameworks providing the infrastructure for them.
There's also no real guarantee that your model is any more or less parallelisable than your views, or your controllers. Event handling might be sequential (per document most likely, as I noted) but drawing is usually independent per view (sometimes parallelisable within a single view). And maybe that all sits atop a SQLite database that's single-threaded. Or not. My point is that it's really about a fundamental mindset; serial by default, or concurrent by default. You'll always have to bridge between the two in project-specific places.
> But if the whole framework is modelled around an outdated concept, you have a bigger problem than if it's just each application that is.
Of course. But we shouldn't be too hesitant to make forward progress for fear of some unknown opportunity cost.
_______________________________________________
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