Somewhere in this email a lightbulb gets turned on!
> On Jun 29, 2015, at 2:49 PM, Scott Ribe <scott_r...@elevated-dev.com> 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 (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
