Re: How do I guarantee that an object is dealloced on the main thread?
Re: How do I guarantee that an object is dealloced on the main thread?
- Subject: Re: How do I guarantee that an object is dealloced on the main thread?
- From: Brian Stern <email@hidden>
- Date: Sun, 5 Oct 2008 17:41:16 -0400
On Oct 5, 2008, at 4:52 PM, Jim Correia wrote:
On Oct 5, 2008, at 4:43 PM, Brian Stern wrote:
This is the question I really wanted to ask:
I have an object X that is alloc/inited on the main thread. This
object creates some NSThreads with
detachNewThreadSelector:toTarget:withObject, which have object X as
their target. At a later point I want to release object X and have
it be dealloced on the main thread.
How do I guarantee that object X is dealloced on the main thread?
The problem is this: the NSThread objects retain object X. I have
a stop method in object X that sets a 'cancelled' global that the
thread objects inspect and they then exit when it turns true. So I
send stop and then release on the main thread. The thread objects
exit and eventually release object X but the last release, which
causes the dealloc, can be on any thread.
The real question is, why do you care what thread the -dealloc
method runs on?
What non-memory management side effects does your -dealloc method
have which much be run on the main thread?
My main reason was just cleanliness. Looking more closely at the code
however, most of which I didn't write, there are some runloop sources
that are removed and calls to NSObject
cancelPreviousPerformRequestsWithTarge:selector:object. Most of the
code that set those things up will have run on the main thread so
should be cleaned up on the main thread. There's some other networking
cleanup that I don't know if it's threadsafe or not.
It's conceivable that I can rework the cleanup so that most of it
happens in the stop method and the dealloc method is mostly empty but
if there's a way to guarantee that dealloc runs on the main thread
then I'd probably prefer that.
I guess from your question you don't have a one sentence answer to my
question.
--
Brian Stern
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden