Re: NSOutlineView threading problem
Re: NSOutlineView threading problem
- Subject: Re: NSOutlineView threading problem
- From: Bill Bumgarner <email@hidden>
- Date: Sun, 15 Jun 2008 17:46:52 -0700
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
other
magic.
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 a
reloadData 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) %@] <%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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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