It sounds, though, as if it should be ok to use observeValueForKeyPath:ofObject:change:context (which will run on the secondary thread, by the sound of it) as a way of monitoring the fact that "something" has changed in the state of my object. I can then use that as a single place in which I schedule a GUI update via a shadow object on the main thread. Does that sound as if it would be ok?
On 23 Mar 2012, at 23:14, Dave Fernandes wrote: > See the Cocoa Design Patterns doc: > "The Receptionist Design Pattern in Practice > A KVO notification invokes the > observeValueForKeyPath:ofObject:change:context: method implemented by an > observer. If the change to the property occurs on a secondary thread, > theobserveValueForKeyPath:ofObject:change:context: code executes on that same > thread." > > So you shouldn't use observeValueForKeyPath:ofObject:change:context to update > the GUI in this context. I don't know of any better method than what the OP > suggested. > > Cheers, > Dave > > On 2012-03-23, at 6:32 PM, Jan E. Schotsman wrote: > >> Jonathan Taylor wrote: >>> I have been struggling with a problem which I think I have eventually >>> realised is down to me not handling multithreading issues properly. The >>> situation is I have some computationally-demanding code that is running in >>> a separate thread. This has input parameters and state variables associated >>> with it. For diagnostic reasons I would like to be able to display the >>> values of the state variables in the GUI. I had intended to do this just by >>> binding to them. However I am getting occasional "message sent to >>> deallocated instance" errors which I suspect are a symptom of the fact that >>> I am Doing It Wrong. Further reading suggests that because of the way >>> bindings work, modifying those state variables is leading to binding/gui >>> type stuff happening away from the main thread, which appears not to be >>> permitted. >> I use KVO for this. Have your main thread observe the state variables >> (declared as properties) and update the GUI in your >> observeValueForKeyPath:ofObject:change:context: method. >> I hope this is elegant enough for you ;-) >> Jan E. >> _______________________________________________ >> >> 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: >> https://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca >> >> This email sent to dave.fernan...@utoronto.ca > _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
