• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Safely terminating a thread, or the dealloc that doesn't dealloc?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Safely terminating a thread, or the dealloc that doesn't dealloc?


  • Subject: Re: Safely terminating a thread, or the dealloc that doesn't dealloc?
  • From: Dustin Voss <email@hidden>
  • Date: Mon, 15 Mar 2004 14:31:18 -0800

On 15 Mar, 2004, at 5:13 AM, Glen Low wrote:

Hi all,

In my kqueue implementation for Graphviz, I have an object that spawns a thread. The thread then occasionally notifies the object of interesting events via performSelectorOnMainThread. The object can also pass messages to the thread via a pipe. Now in order to perform proper termination, the object should send a "kill me" message to the thread. So far so good.

Except...

If the object sends the "kill me" message to the thread during its dealloc, there is a small chance that the thread will still have other pending messages to send to the object, in which case it will crash. In essence, I need to extend the lifetime of the object to the lifetime of the thread.

Some thoughts:

1. In my object dealloc, send the message but don't call super dealloc. Arrange for the thread to call the object one last time, and the last method does the real dealloc. Not quite Cocoa-kosher to me.
2. The thread could retain the object and release it upon its end -- but I doubt retain and release are threadsafe.
3. On dealloc, wait for the thread to terminate. I don't know if you can "join" a thread in Cocoa, but I don't want to incur the overhead of a blocking call.
4. Something else?

If your object is being deallocated, I assume it doesn't actually want to deal with any further messages from the thread. Have you tried calling [NSObject cancelPreviousPerformRequestsWithTarget: self] in your -dealloc method? That might get rid of any requests posted from another thread.

If your object does want to finish up with the thread's business, I don't think the -dealloc method is the place to do that. You could try pushing back up the chain of command: have the owner of the object call a -doneWithPendingBusiness method and not call the final -release if there's something your object still needs to do.

Another possibility is to override -release in your object to delay performing -dealloc until the thread's business is taken care of. This seems cleaner than your thought #1, because until -dealloc is called, the object is still theoretically capable of being retained and saved from death. The implementation might be tricky, though.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.


  • Follow-Ups:
    • Re: Safely terminating a thread, or the dealloc that doesn't dealloc?
      • From: Glen Low <email@hidden>
References: 
 >Safely terminating a thread, or the dealloc that doesn't dealloc? (From: Glen Low <email@hidden>)

  • Prev by Date: Re: nsbutton highlighting
  • Next by Date: Re: Leave NSLog()s in Final Product?
  • Previous by thread: Re: Safely terminating a thread, or the dealloc that doesn't dealloc?
  • Next by thread: Re: Safely terminating a thread, or the dealloc that doesn't dealloc?
  • Index(es):
    • Date
    • Thread