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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
