Well, actually not quite true. Pthreads has that mechanism with the join facility. I like pthreads (er.. did before I began to grok GCD), but personally have no use for pthread-join, and definitely don’t recommend its use, but it does exactly this - waits for another thread to exit before continuing. Pthreads have been in OS X for a very long time…
Now let me repeat. pthread_join is evil, bad, not to be used. There are much better ways of doing things, even in pthreads. And definitely not to be used in the main thread… - Jack Brindle > On Jun 29, 2015, at 2:41 PM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Jun 29, 2015, at 13:50 , Gavin Eadie <ga...@umich.edu> wrote: >> >> The main thread is not involved in the above, but the idea of an >> “asynchronous-that-waits” == “apparently synchronous” call is demonstrated. > > Yes, but you achieved that by blocking a background thread. It works because > you don’t care that the thread is blocked. > > Incidentally, this sort of thing will break GCD. If the background thread was > allocated to your block by GCD and it blocks, GCD will start another thread > to do the next thing in the same queue. In a situation where this can happen > repeatedly, you can end up with unlimited numbers of threads in flight > simultaneously — unlimited until the system crashes, that is. > > OS X (and iOS) have *never* had a thread “yield” mechanism other than > returning to the main event loop. That means that your only valid reply to > the code’s author is, “There’s no way to do what you want.” > > The only exception to this statement — one that it’s really a bad idea to > even present, since it reflects old-fashioned Cocoa design principles from > the 1980s — is the idea of running the run loop modally, which is what > buttons (e.g.) do when you click on them. > > But the real question is, what is the downside of re-factoring the code in > the way Jens suggested? Has the code author tried? That’s what’s frustrating > — after all this discussion, there’s a good chance that re-factoring will > fall out problem-free with about 5 minutes of effort. > > > > _______________________________________________ > > 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/jackbrindle%40me.com > > This email sent to jackbrin...@me.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
