Re: KVO notifications and threads
Re: KVO notifications and threads
- Subject: Re: KVO notifications and threads
- From: Jerry Isdale <email@hidden>
- Date: Fri, 11 Jul 2008 12:22:42 -0700
So having mutiple CPUs and cores doesnt buy us much more than bragging
rights, at least as far as KVO and UI goes. oh well.
I like Clark Cox's suggestion for wrapping the set methods in a
category that forces the actual set to occur on the MainThread
note to Apple developers observing:
it would be really nice to make the MVC and KVO play nicely with
threads.
On Jul 11, 2008, at 11:50 AM, Ken Thomases wrote:
On Jul 11, 2008, at 11:30 AM, Jerry Isdale wrote:
I have an application whose data model (classes, shared Instances,
etc) gets updated by various threads for calculations, network
comms, etc.
Some of the application's Views use binding and KVO. For example
an NSTextField may get bound to SharedInstance.currentLattitude
It the property gets updated using KVO compliant code, on what
thread is the NSTextField updated?
Possible answers include:
* thread that invokes the set method
* MainThread - because all UI updates should happen there.
Perhaps the KVO means that the View gets marked as needing an
update in next update cycle, and thus we have a combination of
these two answers:
* invoking thread marks the View for update
* MainThread does the update in its next graphics update cycle
The answer is: you're playing with fire and will be burned.
Bindings to the GUI don't play well with threading.
All KVO notifications are delivered on the thread where the property
is changed ("thread that invokes the set method"). The controllers
and views which are typically on the receiving end of those
notifications are not thread-safe. That is, if the main thread is
working with the state of those objects and a background thread is
manipulating that state in response to a KVO notification, the two
won't play nicely together -- there's no attempt to synchronize.
You need the facade of your model to appear to be single threaded.
If there's work going on in background threads, those threads should
not directly manipulate state which can be queried from GUI
bindings. Instead, you can use performSelectorOnMainThread:... when
a background thread has a transaction ready to commit to pass that
transaction to the main thread for committing.
Cheers,
Ken
Jerry Isdale
email@hidden
_______________________________________________
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