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
