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: Gavin Eadie <email@hidden>
- Date: Mon, 29 Jun 2015 16:50:54 -0400
Somewhere in this email a lightbulb gets turned on!
> On Jun 29, 2015, at 2:49 PM, Scott Ribe <email@hidden> wrote:
>
> The problem is that the requirement is self-contradictory: "synchronous" means wait, and "without impacting performance" means don't wait. While the real requirement is probably more like "do certain things while the bg task is running, then do something else when it completes". To really answer the question, you have to break down what needs to be while the bg task is running and what has to be done after, then categorize those into the type of tasks, such as whether or not they interact with UI and thus have to run on the main thread, and so on.
This is all true for a “really synchronous” call, but my suggestion is that an “apparently synchronous” call only appears to wait; using a semaphore can stop the return, while things keep working on other threads. My friend’s example, when not called from the main thread, works perfectly:
wrapper {
// Send the request to the device
[camera requestSendPTPCommand:command outData:myData
sendCommandDelegate:sharedCameraController
didSendCommandSelector:@selector(didSendPTPCommand:inData:response:error:contextInfo:)
contextInfo:request];
// Wait for the delegate response
dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);
// Continue
}
in the delegate “didSendPTPCommand:inData:response:error:contextInfo:” I have a dispatch_semaphore_signal(sem);
The main thread is not involved in the above, but the idea of an “asynchronous-that-waits” == “apparently synchronous” call is demonstrated.
But while an “asynchronous call that waits” has been demonstrated as a viable construct in a non-critical context, the critical nature of the main thread (namely, app performance requires access to its runloop) renders the construct useless because the wrapper above takes us off the main thread and, no matter what we do, until we return to it, the runloop is out of reach.
> It sounds to me like your friend is trying to avoid that level of analysis with a hand-wavy magic solution that both waits and does not wait. Sorry, but it's time to open that box and see if the damned cat is dead or not ;-)
.. one of my two cats hisses in the general direction of your email !
_______________________________________________
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