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