• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Cheating a synchronous call on the main thread
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Cheating a synchronous call on the main thread


  • Subject: Cheating a synchronous call on the main thread
  • From: Gavin Eadie <email@hidden>
  • Date: Mon, 29 Jun 2015 12:14:08 -0400

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 (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


  • Follow-Ups:
    • Re: Cheating a synchronous call on the main thread
      • From: Dave <email@hidden>
    • Re: Cheating a synchronous call on the main thread
      • From: Jens Alfke <email@hidden>
    • Re: Cheating a synchronous call on the main thread
      • From: Scott Ribe <email@hidden>
  • Prev by Date: Bridging CFArrayRef and NSArray
  • Next by Date: Re: Open program from custom schema link
  • Previous by thread: Bridging CFArrayRef and NSArray
  • Next by thread: Re: Cheating a synchronous call on the main thread
  • Index(es):
    • Date
    • Thread