Re: Cheating a synchronous call on the main thread
Re: Cheating a synchronous call on the main thread
- Subject: Re: Cheating a synchronous call on the main thread
- From: Dave <email@hidden>
- Date: Tue, 30 Jun 2015 11:20:42 +0100
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 <email@hidden> 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 (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden