Re: Thread deadlock?
Re: Thread deadlock?
- Subject: Re: Thread deadlock?
- From: Peter Duniho <email@hidden>
- Date: Mon, 11 Aug 2008 10:47:46 -0700
Date: Mon, 11 Aug 2008 12:09:05 +0000
From: Trygve Inda <email@hidden>
I am seeing a deadlock I think... It works in the debugger, but
hangs when
running alone. The killThread is called as part of the
applicationWillTerminate delegate method.
My thought is that somehow after blocking to wait for
kConditionThreadIdle,
my performSelectorOnMainThread is getting called. When this
happens, it gets
stuck because the main thread is already blocked.
Perhaps after calling if (![self threadMustExit]), but before
dispatching to
the main thread? [...]
Perhaps. Is the "killThread" method executed on the main thread? If
so, then yes...it would get stuck waiting for the the
"kConditionThreadIdle" condition. If the main thread reached that
code any time before the "doThreadUnsafeStuff" method was actually
executed on the main thread, then that selector will never be
performed, the worker thread will never get past the
"performSelectorOnMainThread" statement, and will itself never
release the main thread.
Sounds like deadlock to me. Hard to know for sure, since the code
you posted isn't a complete sample, nor would it even compile, so
it's obviously not actually the code you're using. But assuming it's
a fair representation, it looks like it has a deadlock bug in it.
For what it's worth, it seems to me that blocking the main thread for
_any_ significant time is just a bad idea. I'm less familiar with
Cocoa, but this is true in every other message/event-dispatching
architecture I'm familiar with. That's the main reason for putting
lengthy operations on a different thread in the first place, and
making the main thread wait on such a lengthy operation negates the
whole point of putting that operation on a different thread.
So even if you weren't calling "performSelectorOnMainThread", waiting
on the worker thread is probably not a great idea. Of course, in
your example, it's _definitely_ not a great idea. :)
By the way, I admit...I'm not familiar with the exact usage of
NSConditionLock, but it would surprise if you have to take the lock
just to inspect the condition (per the "threadMustExit" method).
Pete
_______________________________________________
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