On Wed, Nov 19, 2008 at 3:57 PM, Jean-Nicolas Jolivet <[EMAIL PROTECTED]> wrote: > I have an app that generates a bunch of images... the process can be long so > I wanted to start it in a separate thread so that the UI can be responsive > etc... > > basically the only thing I did was: > > [NSThread detachNewThreadSelector:@selector(doLongProcess) toTarget:self > withObject:nil]; > > and I added > > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > > at the beginning of my doLongProcess method, and [pool release] at the > end... > Now the weird part is that... it appears to be working... the images are > created...the UI stays responsive..my status textfield gets updated (it > wasn't getting updated when the long process was not in a separate > thread)... > > Am I wrong to think that it should've been much more complex than that? > (With NSLocks and whatnot...) Maybe I should just shut up and be happy that > it work, but somehow this doesn't seem right...
The basic principle of multithreaded programming is this: always synchronize access to mutable shared data. In an environment like Cocoa it becomes complex for a couple of reasons. First, data can be shared not only within your code but with the framework. This is why most of AppKit is not safe to call from anywhere except the main thread. The framework has access to all those tasty AppKit objects too, and the only way to synchronize access is to make everybody use the same thread for it. Second, when dealing with objects, "mutable" is very difficult to discern. This "mutable" is not the same one as the one we look at when we examine NSArray vs NSMutableArary. That mutable just means that the contents of the NSArray don't change. The threading mutable means that the *internal data structures* of the NSArray don't change. There are all sorts of reasons why an immutable NSArray might still want to change its internal data structures when things happen. So when dealing with unknown objects whose thread safety is not documented, you cannot access them from multiple threads without synchronization just because they present an immutable interface. (As it happens, NSArray *is* documented to be thread safe, but that was just an example.) So you got away without synchronization. How? Perhaps your shared data truly was immutable, or documented as thread safe. If so, then you did everything right. If not, then you may simply be getting lucky. One of the painful things with threaded programming is that it's very easy to do things incorrectly and still succeed... most of the time. Are you also updating the text field from the thread? If so, that's disastrously wrong, and you need to use performSelectorOnMainThread: to manipulate any GUI objects, and it's working by luck. Pure worker threads are generally pretty easy to do without a lot of synchronization though, so what you're seeing isn't a big surprise. If all you do is take a bunch of data and transform it into another bunch of data, you can pretty much just pass that bunch of data off into a worker thread, let it churn, and then get the result back when it's finished. Mike _______________________________________________ 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]
