Re: Safely terminating a thread, or the dealloc that doesn't dealloc?
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: Glen Low <email@hidden>
- Date: Mon, 15 Mar 2004 23:19:00 +0800
Joar, all:
On 15/03/2004, at 9:27 PM, j o a r wrote:
On 2004-03-15, at 14.13, Glen Low wrote:
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.
Not so nice...
2. The thread could retain the object and release it upon its end --
but I doubt retain and release are threadsafe.
I would think that they are, but it still wouldn't work - as the
retain/release machinery is disabled once an object has entered
dealloc.
Yeah, I could do this in my object release when retainCount == 1,
figuring that the thread had the last retain on the object, but this
sounds rather fragile to me.
4. Something else?
I wouldn't do this in dealloc. Don't you have some other point where
you can tell the object to kill it's thread, and then remove itself?
Also, couldn't the thread clear it's queue of pending messages when it
receives the "kill me" message?
See point above.
The thread can't clear its queue because the queue for
performSelectorOnMainThread is not under its control.
Maybe I'm being too paranoid. The doco says the receiver for
performSelectorOnMainThread is retained until the perform is complete,
so that should mean the object will still be around until after
perfomSelectorOnMainThread does it job. Still doesn't deal with the
case when the object is dealloc'ed before perform is called...
Cheers, Glen Low
---
pixelglow software | simply brilliant stuff
www.pixelglow.com
_______________________________________________
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.