It's tempting to try my hand at extending SimplePicture, such as a progress indicator (blah of blah blah images) and updating the list every 100 images or so. But I'm behind schedule with Historian. I do have a question, though. In - (void)threadedReloadImageList: [self performSelectorOnMainThread: @selector(setImageList:)
withObject: imageList
waitUntilDone: NO];
[imageList release]; [pool release];
Since we're not waiting until done, do we run into any race conditions of imageList, and any images in the pool, being fully released before setImageList: is run?
Is there any advantage to having the thread end ASAP? In other words, if waitUntilDone is YES, does having an inactive thread around longer hurt things? I'm looking mostly at pool release, which apparently is fast. I know this is a mostly trivial question in this case, but I'm thinking about responsiveness/speed tradeoffs in my own multithreaded app.
@Coriander: Good point about inLiveResize.
Offtopic: Interesting about the original screenshots. I'd ask about how the shift in advertising's affected things, but this isn't the place.
by Blain — Oct 03
[self performSelectorOnMainThread: @selector(setImageList:) withObject: imageList waitUntilDone: NO]; [imageList release]; [pool release];Since we're not waiting until done, do we run into any race conditions of imageList, and any images in the pool, being fully released before setImageList: is run?
Is there any advantage to having the thread end ASAP? In other words, if waitUntilDone is YES, does having an inactive thread around longer hurt things? I'm looking mostly at pool release, which apparently is fast. I know this is a mostly trivial question in this case, but I'm thinking about responsiveness/speed tradeoffs in my own multithreaded app.
@Coriander: Good point about inLiveResize.
Offtopic: Interesting about the original screenshots. I'd ask about how the shift in advertising's affected things, but this isn't the place.