On Sep 26, 2015, at 16:49 , Jerry Krinock <je...@ieee.org> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
