> On Sep 28, 2015, at 12:13 AM, cocoa-dev-requ...@lists.apple.com > <mailto:cocoa-dev-requ...@lists.apple.com> wrote: > > Thank you, John. You are referring to what my secondary thread is doing. My > point is that if we can’t at least rely on -[NSThread start] returning before > the secondary starts, there is no way for a seconary thread to call back to > the main thread without possibility of deadlock. It’s a defect in NSThread. > >> Data sharing using serial queues is safer and more robust by design. > > OK, if it is a defect in NSThread, GCD might not have this defect. I’ll > consider that. Thank you.
It is not a defect in NSThread. That is just a subtlety the way it works. In this model, there are three potential situations when -[NSThread start] returns: 1) Your thread hasn’t started yet 2) Your thread has started and is running 3) Your thread has completed Your code must handle all of these possibilities. GCD is just a different model and has different subtleties. GCD may not spawn any new “threads” at all. You would think in terms of queues and blocks instead. GCD encourages a more straightforward producer-consumer architecture. You can use that architecture for your NSThread code too and get more robust behaviour. In general, you really don’t want to think about what your threads might or might not be doing or what state they might be in. Use locks around any structures that could be shared. Use semaphores to enforce any sequential behaviour if you need that. John Daniel i...@etresoft.com <mailto:i...@etresoft.com> John Daniel i...@etresoft.com _______________________________________________ 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
