Is it safe to to self destruct an NSThread?

Question

Hey all,

I have a pretty standard setup. I have a UIViewController to handle user interaction and a somewhat long running NSThread that does the actual work when the UI Controller shows up. One issue I've had is when I want to cancel the NSThread. Standard NSThread semantics is alright. I want the thread to finish, clean itself up (so that it releases the reference to my UIViewController) and then pop the UIViewController. So my code looks something like this:

In NSThread selector:

-(void) nsThreadWork
{
  // do work here
  @synchronized(self)
  {
    [nsThreadInstance release];
    nsThreadInstance = nil;
  }
}

In UIViewController that spawns the thread:

 -(void) startThread    
 {
   nsThreadInstance = [[NSThread alloc] initWithTarget:self 
                                        selector:@(nsThreadWork) ...];
   [nsThreadInstance start];
   [nsThreadInstance release];
 }

And if I want to cancel:

// assume that this will be retried until we can execute this successfully.
-(void) cancelBackgroundOpAndPopViewController
{
  @synchronized(self)
  {
    if (nsThreadInstance == nil)
    { 
        [self popViewController];
    }
  }
} 

I doubt if this is correct though. The problem is, UI elements can only be manipulated from the main thread. If I pop the view controller before NSThread exits, NSThread will exit and release the view controller which means it will be dealloced from NSThread's context which will cause an assert. Everything appears to work properly with the above code, but I dont understand when the runloop deallocates NSThread. Can anyone provide any insight?