On Fri, Feb 20, 2009 at 6:25 PM, Luke Evans <l...@eversosoft.com> wrote: > The more I'm getting to know Cocoa (we're still not intimate), the more it > seems that regular apps with UI making use of features like Core Data etc. > need to be architected very centrally around the main thread - it's only > easy/safe to use background threads for activities that perform discrete > processing and post their results back to some agent waiting back on the > main thread.
Cocoa is just fine with doing lots of stuff on background threads. What's not fine is doing any UI stuff on background threads. Practically speaking, it means that in such a multithreaded app, when you do your MVC design, the view side must be done only from the main thread. The model can run on any thread (assuming a proper multithreaded design there), and then your controller layer needs to mediate between the two to ensure that when the UI changes the model the proper synchronization is performed, and that when the model performs an update that needs to be reflected in the UI, all such updates are shipped back to the main thread before hitting the UI. The trouble you're having here is not with Cocoa, but with Cocoa bindings. Bindings fit into the controller layer of MVC and have absolutely *no* awareness of multithreading whatsoever. If you want to multithread your model, you either need to abandon bindings (my favored course of action) or bind to a layer of your model which is main-thread-only, and which serves as a proxy to the multithreaded section. Mike _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
