Re: -[NSThread start] blocks ?!?
Re: -[NSThread start] blocks ?!?
- Subject: Re: -[NSThread start] blocks ?!?
- From: Quincey Morris <email@hidden>
- Date: Sat, 26 Sep 2015 18:03:12 -0700
- Feedback-id: 167118m:167118agrif8a:167118sYueBCLE3C:SMTPCORP
On Sep 26, 2015, at 16:49 , Jerry Krinock <email@hidden> wrote:
>
> By “starter thread”, I presume you mean the one which is invoking -[NSThread start].
Yup.
> If what you are saying is true, how could we ever execute -performSelectorOnMainThread::: in a secondary thread without possibility of deadlock?
I don’t understand what you’re asking. There’s no question of deadlock unless the threads wait on each other, directly or indirectly, and you don’t seem to have mutual waits in your code. (Of course, it could still happen as an unwanted interaction between what your worker thread does and what the system does.) The scenario I was talking about involved only delays that would eventually be resolved. (I was answering your question, not diagnosing your problem.)
All your stack traces have an identical call to _OSSpinLockLockSlow as their second entry. Looks like everything is waiting on a single lock that’s part of the threading machinery. Since you’ve apparently created over 450 threads previously, perhaps you used up kernel resources to the point where whatever took the lock crashed without releasing it?
Sorry, I’m not very clever at debugging things like this. :(
_______________________________________________
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