This kind of approach doesn't make sense and introduces a lot of issues. You occupy a thread which just waits for a result of a task (and thus merely blocks). You doesn't cancel the async task properly when a timeout occurs. And additionally you introduce a potential data race.
You could avoid all that by simply following asynchronous patterns: just implement the continuation (completion handler) of the already given asynchronous method. Andreas > Am 30.06.2015 um 12:20 schrieb Dave <d...@looktowindward.com>: > > Hi, > > I do something like this which works really well but NOT on the Main Thread, > on a background thread. > > > -(NSData*) performSyncRequest > { > dispatch_group_t myDispatchGroup; > > //** > //** Create and Enter a Dispatch Group > //** > myDispatchGroup = dispatch_group_create(); > dispatch_group_enter(myDispatchGroup); > > [self doSomethingWithCompletionHandler: > ^(NSError* theErrorInfo) > { > > //** > //** Signal Response Received > //** > dispatch_group_leave(myDispatchGroup); > } > ]; > > > //** > //** Wait for the Response - Check for Time-Out Error > //** > myTimeOutStatus = > dispatch_group_wait(myDispatchGroup,dispatch_time(DISPATCH_TIME_NOW,kLTWNetworkOperationTimeOutPeriodNS)); > if (myTimeOutStatus != 0) > { > dispatch_group_leave(myDispatchGroup); > } > > //** > //** Handle Request Completed - Perform any delegate methods > //** > NSData* myRequestData = [self getData]; > > dispatch_release(myDispatchGroup); > > return myRequestData; > } > > Cheers > Dave > > >> On 29 Jun 2015, at 17:14, Gavin Eadie <ga...@umich.edu> wrote: >> >> It’s standard knowledge that any operation which causes an app’s main thread >> to wait is bad, and that diverting such delays off the main thread allows >> the app to remain optimally responsive to external events. That diversion >> can happen via a couple of mechanisms: ‘callbacks’ (delegation and >> closures) that are inherent in an API; and explicit transfer via GCD (or >> NSOperation at a more abstract level). >> >> My question for the list originates with a friend who is updating an app in >> which previously synchronous call needs to be replaced by asynchronous one >> (a Image Capture Core method, using a delegate). Leaving aside, if >> possible, the reasons for this, he has retained an apparent synchronous >> nature of the original call by wrapping the new ‘requestSend..’ method and >> its corresponding ‘didSend..’ delegate so that the wrapper appears to block >> its thread while actually allowing the main run loop to execute. >> >> The intent is to have code of the form: >> >> .. before >> fakeSyncrony >> after .. >> >> where, though “fakeSyncrony” is actually internally asynchronous, >> “after” is not executed till after the its delegate action completes. >> >> This works well if the above code executes off the main thread because any >> waiting inside “fakeSyncrony” can happen in the main run-loop and >> responsiveness is retained. >> >> It does not work if that code is on the main thread because there’s no way >> to put the waiting on the, now already occupied, main thread, and that’s >> where the question lies. While it seems clear to me and my friend that this >> in an inescapable fact of life, we have a counterexample in the form of the >> Canon ED-SDK, which somehow does accomplish this. >> >> Can anyone, with more knowledge than we have, suggest a trick that allows an >> apparently synchronous call on the main thread without impacting performance? >> >> PS: If I was answering this question, I’d suggest getting off the main >> thread and not playing tricks. So the answer “Don’t do this!” is already >> very high on the list .. another answer, regardless of nastiness, does exist >> but it’s beyond my skill to devise, but there are much smarter people than I >> on this list! >> _______________________________________________ >> >> 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/dave%40looktowindward.com >> >> This email sent to d...@looktowindward.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/agrosam%40onlinehome.de > > This email sent to agro...@onlinehome.de _______________________________________________ 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