Re: Multithreading question
Re: Multithreading question
- Subject: Re: Multithreading question
- From: Chris Hanson <email@hidden>
- Date: Thu, 17 Nov 2005 14:57:10 -0800
On Nov 17, 2005, at 8:57 AM, email@hidden wrote:
My application is processing several audio files in a thread.
Several views (for now a NSTableView, a NSProgressIndicator and a
NSTextField)
are used to display what's going on in the processing thread.
Actually, these
views are updated automatically using Bindings, from a model class
representing
the progress of the processing thread and the tasks to be performed.
Key-value observing and Cocoa bindings (which are built on KVO) are
not thread-safe. You cannot safely modify a property that is being
observed -- via a binding or otherwise -- from any thread other than
the main thread. You also cannot make doing so safe using locks,
since you cannot cause Cocoa to obey your own locking scheme.
Your best bet is to have your processing threads communicate with
your data model via a thread-safe communication mechanism (a shared
thread-safe queue, Distributed Objects, or the method -
performSelectorOnMainThread:withObject:afterDelay:) in order to
perform updates etc.
I experienced several UI glitches (text overlays, strange
NSProgressIndicator behaviour) and I found out that there was an
issue with
threads.
See the documentation on multithreading in Cocoa. You cannot assume
any functionality in any framework is thread-safe; you must assume
any functionality is not thread-safe unless explicitly documented
otherwise. (This applies generally, not just to Cocoa or Mac OS X.)
- In the processing thread, call all the model/controller methods with
performSelectorOnMainThread so that they will run in the main thread.
Even better, call your own methods using this mechanism, and have
your methods call the appropriate model/controller methods. An extra
layer of abstraction can be useful in situations like this.
-- Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden