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