Re: -[NSThread start] blocks ?!?
Re: -[NSThread start] blocks ?!?
- Subject: Re: -[NSThread start] blocks ?!?
- From: Jerry Krinock <email@hidden>
- Date: Sat, 26 Sep 2015 16:49:54 -0700
> On 2015 Sep 26, at 15:53, Quincey Morris <email@hidden> wrote:
>
> On Sep 26, 2015, at 15:33 , Jerry Krinock <email@hidden> wrote:
>>
>> Should not -[NSThread start] always return before running any of my code in the new thread?
>
> You have absolutely no control over it, unless you introduce your own synchronization mechanisms.
>
> The *earliest* it can return is before the new thread has had a chance to run initially. But the starter thread is competing for chances to run with every other thread on the system, so it can be delayed by any other thread, including the one it started, up to and beyond the point when the worker thread exits.
Thank you, Quincey. By “starter thread”, I presume you mean the one which is invoking -[NSThread start]. In this case, the “starter thread” is in fact the main thread.
This does look like a deadlock between my worker thread and the main thread. If what you are saying is true, how could we ever execute -performSelectorOnMainThread::: in a secondary thread without possibility of deadlock?
This apparent deadlock has been on my MacBook Air, which has only 2 cores, for about 3 hours now.
_______________________________________________
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