> On 2015 Sep 26, at 15:53, Quincey Morris > <[email protected]> wrote: > > On Sep 26, 2015, at 15:33 , Jerry Krinock <[email protected]> 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 protected]) 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 [email protected]
