On Jun 15, 2008, at 2:36 PM, David wrote:
What I thought I was doing seems to be working. I am able to run a secondary thread, adding nodes to the tree I'm displaying in the primary thread. All problems appear to have been resolved. No need for locking or any othermagic.I think folks are a little too spooked by Apple saying that Cocoa isn't thread safe. That doesn't mean you have to avoid threads like the plague.
That opinion will get you into lots of trouble. Lots and lots of trouble. Trouble in the form of "it crashes all the time on 15% of my customers machines but I can't reproduce it".
How do you know your code works? Have you tested across all of the different CPUs Apple ships? There are radical differences in the way the kernel ends up scheduling threads depending on # of cores and bus throughput. How about under scarce memory situations when some other app is eating all of memory and your app's thread's scheduling is skewed by page faults? Or on a many-core system where some other app is using lots of CPU? Or how about on Mac OS X 10.5.7 or 10.6 or 10.7 or 11.1 or any other release that may change the behavior of the not-thread-safe class because it... well... isn't thread safe. How about in all of the different locales around the world? Rendering asian character sets and/or right-to-left text can have a huge impact on the main thread's CPU usage and, thus, your background thread's interleaved scheduling is gonna be totally different.
If a class is documented as not being thread safe, do **not** use it from multiple threads. Period. End of story. This includes locking the ever living heck out of it -- it may be "not thread safe" because it internally uses bits of the AppKit or Foundation that are not thread safe.
If you are going to use threads with Cocoa, do so carefully and do so by following the documentation carefully. Assumptions will lead to nasty bugs.
The problem was that when I was done adding nodes on the 2nd thread, I was sending a notification. When the notification was received, I was doing areloadData and display on the outline view.
Yup. That'll do it! Good use of NSLog(), there. I have a macro floating around that does this:
NSLog(@"%@ [%@(0x%x) [EMAIL PROTECTED] <%your stuff%>", [NSThread currentThread], [self class], self, NSStringFromSelector(_cmd)<%args%>);
Totally invaluable for debugging these kinds of issues.I would highly recommend that you look long and hard at how are you are managing the data structures that are also used by NSOutlineView. In particular, if you are futzing with an NSMutableArray from one thread while the AppKit is enumerating it in another, that can be very problematic. In particular, NSMutableArray may effectively realloc() its contents as it crosses certain capacity thresholds. If the other thread happens to be in the middle of reading from the old buffer at that time, well... *boom*.
b.bum
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
