Re: inconsistent crash drawing a string in a custom browser cell
Re: inconsistent crash drawing a string in a custom browser cell
- Subject: Re: inconsistent crash drawing a string in a custom browser cell
- From: Shawn Erickson <email@hidden>
- Date: Wed, 07 Jun 2006 13:31:15 -0700
On Jun 7, 2006, at 1:04 PM, Graham wrote:
I am running Tiger 10.4.6.
I placed the crash log on my website since it is 103k: http://
gragsie.com/FlickrFinder/Flickr Finder.crash.log
Interesting you have over 100 threads going in your application with
most of them in -[ThumbCell loadAsynchronously]. I assume you just
fork threads for each ThumbCell you have?
I strongly recommend that you switch to using a thread pool for such
asynchronous activity. Really no need to have that many threads
loading (what I assume is remote) information and triggering its
display. I bet things would perform better if you limit the thread
pool to just a few threads (seldom more then 10 should be needed).
Depending on the size of the data requested, end users bandwidth, and
target servers load having that many loads going at the same time can
easily degrade performance.
Also I notice that those secondary threads are updating the UI. In
general the UI should only be updated from the main thread (thread
0). This may be causing the crash you are hitting.
It is hard to tell from the backtraces if you are taking the proper
steps to ensure you can update the UI from a secondary thread (the
fact that many are sitting waiting for a view hierarchy lock implies
you aren't... well at least they shouldn't be sitting their if you
did the proper locking before asking the cell to draw). Personally I
recommend you only update your UI from the main thread, consider
using -[NSObject
performSelectorOnMainThread:withObject:waitUntilDone:] from your
secondary threads.
You could also look at using just one thread to do your async loading
(could even do it on the main thread depending on the load). In this
secondary thread you could run a runloop and schedule loading
callbacks on that runloop... you can have multiple loads outstanding
that way while only having a single thread doing the final data
shuffling.
-Shawn
_______________________________________________
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