title: NSThread vs. NSOperationQueue vs. ??? on the iPhone
body: <p>Currently I'm using <code>NSThread</code> to cache images in another thread.</p>
  
  <pre><code>[NSThread detachNewThreadSelector:@selector(cacheImage:) toTarget:self withObject:image];
  </code></pre>
  
  <p>Alternately:</p>
  
  <pre><code>[self performSelectorInBackground:@selector(cacheImage:) withObject:image];
  </code></pre>
  
  <p>Alternately, I can use an <code>NSOperationQueue</code> </p>
  
  <pre><code>NSInvocationOperation *invOperation = [[NSInvocationOperation alloc] initWithTarget:self selector:@selector(cacheImage:) object:image];
  NSOperationQueue *opQueue = [[NSOperationQueue alloc] init];
  [opQueue addOperation:invOperation];
  </code></pre>
  
  <p>Is there any reason to switch away from <code>NSThread</code>? GCD is a 4th option when it's released for the iPhone, but unless there's a significant performance gain, I'd rather stick with methods that work in most platforms.</p>
  
  <hr>
  
  <p>Based on @Jon-Eric's advice, I went with an <code>NSOperationQueue</code>/<code>NSOperation</code> subclass solution. It works very well. The <code>NSOperation</code> class is flexible enough that you can use it with invocations, blocks or custom subclasses, depending on your needs. No matter how you create your <code>NSOperation</code> you can just throw it into an operation queue when you are ready to run it. The operations are designed to work as either objects you put into a queue or you can run them as standalone asynchronous methods, if you want. Since you can easily run your custom operation methods synchronously, testing is trivially easy.</p>
  
  <p>I've used this same technique in a handful of projects since I asked this question and I couldn't be happier with the way it keeps my code and my tests clean, organized and happily asynchronous.</p>
  
  <p>A++++++++++
  Would subclass again</p>