Re: Binding and multithreading
Re: Binding and multithreading
- Subject: Re: Binding and multithreading
- From: Jonathan Taylor <email@hidden>
- Date: Sat, 24 Mar 2012 09:46:06 +0000
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 (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
>
_______________________________________________
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