Re: EXC_BAD_ACCESS with NSAutoReleasePool, NSThread and NSThreadWillExitNotification
Re: EXC_BAD_ACCESS with NSAutoReleasePool, NSThread and NSThreadWillExitNotification
- Subject: Re: EXC_BAD_ACCESS with NSAutoReleasePool, NSThread and NSThreadWillExitNotification
- From: Ken Thomases <email@hidden>
- Date: Wed, 15 Oct 2008 00:37:29 -0500
I realize you've already identified the cause of the crash but...
On Oct 14, 2008, at 9:38 AM, John Zorko wrote:
... and the threadStopped method does this:
- (void)threadStopped
{
NSLog(@"*** streamer thread has stopped ***");
[[NSNotificationCenter defaultCenter] removeObserver:self];
appDelegate.playbackThreadFinished = true;
}
Now, in my main thread, I have an observer on playbackThreadFinished
that I set up as soon as the app launches (before the other thread
is created):
[self addObserver:self forKeyPath:@"playbackThreadFinished" options:
0 context:nil];
... and when I see the "playbackThreadFinished" notification, I do
things like see if there is a new song to play, etc.
There's an important consideration to be aware of. First, the
NSThreadWillExitNotification notification is delivered in the thread
which is about to exit. Therefore, your threadStopped method and its
"appDelegate.playbackThreadFinished = true;" statement are executed in
that same thread. So, the KVO change notification that results from
"appDelegate.playbackThreadFinished = true" is also delivered on that
thread. For either kind of notification, it doesn't matter on what
thread the observer was registered. It only matters on what thread
the notification was posted or the property change was made.
However, in -observeValueForKeyPath:... you are performing operations
on GUI controllers which will presumably have knock-on effects on GUI
views, etc. Those sorts of things aren't allowed on any thread but
the main thread. You're probably going to get yourself in trouble.
The solution is to use -performSelectorOnMainThread:... to move the
updates of any properties which might be observed using KVO and
bindings to the main thread.
In fact, I'm not sure why you're using NSThreadWillExitNotification
nor KVO on the playbackThreadFinished property. Your design might be
considerably simplified if your thread method -startInternal were to
simply use -performSelectorOnMainThread:... as its last action to
invoke a method on the main thread to take care of any post-threaded-
operation work.
More generally, since all of this work is happening within one class,
there should be little reason for it to observe its own properties.
If you want to perform work when one of your own properties changes,
the cleaner approach is to put that work into the setter for the
property.
Cheers,
Ken
_______________________________________________
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