On Jul 11, 2008, at 2:36 PM, Bill Bumgarner wrote:
If you have specific enhancement requests, please file a bug via http://bugreporter.apple.com
. If your request is "make MVC and KVO play nicely with threads",
you will need to provide details on exactly what you mean -- exactly
how that is to be achieved.
I've got a bug filed along these lines: rdar://5953181 (mistakenly
filed under OS X Server :/). The main times I've come across this
problem is when I want to show the progress of a background operation
by binding some property to a progress indicator. Thus, instead of
doing this:
self.progress = newProgress;
I resort to setting "progress" on the main thread using
performSelectonOnMainThread: + no wait, similar to Clark's
suggestion. I figure not waiting allows the background thread to
continue to maintain decent concurrency. [1]
I'm not sure of the best way to make threads + Cocoa bindings play
nice. My current thinking is to have AppKit bounce all KVO
notifications over to the main thread. It could use NSThread's
isMainThread to conditionally bounce the notification to the main
thread. It could even coalesce notifications, as Ben suggested.
Another possibility is to have have another @property option which
forces that property to only be updated on the main thread. Or maybe
just have the willChange/didChange happen on the main thread.
Or finally, maybe NSController should take care of bouncing model KVO
notifications to the main thread.
My gut tells me this should be done in AppKit. The model and the view
should be completely isolated from each other. Forcing the model to
so stuff on the main thread because the view (i.e AppKit) is not
thread safe seems like breach of MVC. If AppKit is not thread safe,
then AppKit should be responsible for not crashing in the face of
threads. Making AppKit thread is not at all the right solution, but
bouncing KVO notifications seems to be a decent one. While it may be
a performance bottleneck, it's certainly better than nondeterministic
crashing, which is what we get with the current behavior. I can
always Shark it to improve performance, which I'd rather do than hunt
down some non-100%-reproducible crasher.
-Dave
[1]: I've written a little helper to make performing on the main
thread a little easier, especially when dealing with primitive types:
<http://www.dribin.org/dave/blog/archives/2008/05/22/invoke_on_main_thread/
>
Thus, you can write:
[[self dd_invokeOnMainThread] setProgress:newProgress];
without having to box up newProgress as an NSNumber. It's done for
you by forwardInvocation:.
_______________________________________________
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 [EMAIL PROTECTED]
