• 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
Re: Carbon -> Cocoa
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Carbon -> Cocoa


  • Subject: Re: Carbon -> Cocoa
  • From: Alastair Houghton <email@hidden>
  • Date: Thu, 23 Aug 2018 11:06:58 +0100

On 22 Aug 2018, at 19:32, Jens Alfke <email@hidden> wrote:
>
>> On Aug 22, 2018, at 10:40 AM, Alastair Houghton
>> <email@hidden <mailto:email@hidden>> wrote:
>>
>> Well, yes and no. If the network library works that way, it’ll fire its
>> callbacks on the background thread, which makes life awkward if you’re
>> interacting with the UI
>
> Then you write glue around the callbacks that dispatches them on a selectable
> dispatch queue. (Which you'll want to do anyway, because who wants to work
> with C callbacks?)

You’ll take a performance hit doing that; not sure how large, but some, for
sure. Not necessarily a big issue for most apps, but worth bearing in mind.

>> Much better to use a library that’s properly integrated with the native run
>> loop and that therefore doesn’t end up calling your code on a background
>> thread.
>
> To be pedantic, both NSURLSession and Network.framework are based on dispatch
> queues, not runloops. They call delegate code on the dispatch queue assigned
> to the task.

Run loops are based on dispatch queues too, these days.

> Anyway, I agree with you that using a library integrated with OS facilities
> is better than one that isn't. But developers using non-HTTP protocols, or
> coding in C/C++, don't have that luxury … not until they can move up to iOS
> 12 / macOS 10.14 as their deployment SDKs.  In my case that's probably about
> three years away. :(

It’s worth checking whether any of the other libraries have dispatch queue or
run loop integration. It wouldn’t surprise me if some of them do — it isn’t
much of a stretch, once you have an async I/O library, to add the necessary
support. That was sort of the point I was making, namely that it’s worth
looking carefully at the available options to see which have the platform
support you need to make them interoperate well with your platform specific
code (without necessarily being platform specific themselves).

Kind regards,

Alastair.

--
http://alastairs-place.net

_______________________________________________

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: Carbon -> Cocoa
      • From: Tor Arne Vestbø <email@hidden>
References: 
 >Carbon -> Cocoa (From: Casey McDermott <email@hidden>)
 >Re: Carbon -> Cocoa (From: Sean McBride <email@hidden>)
 >Re: Carbon -> Cocoa (From: Stephane Sudre <email@hidden>)
 >Re: Carbon -> Cocoa (From: Jens Alfke <email@hidden>)
 >Re: Carbon -> Cocoa (From: Jean-Daniel <email@hidden>)
 >Re: Carbon -> Cocoa (From: Mike Crawford <email@hidden>)
 >Re: Carbon -> Cocoa (From: Alastair Houghton <email@hidden>)
 >Re: Carbon -> Cocoa (From: Jens Alfke <email@hidden>)
 >Re: Carbon -> Cocoa (From: Alastair Houghton <email@hidden>)
 >Re: Carbon -> Cocoa (From: Jens Alfke <email@hidden>)

  • Prev by Date: Re: Carbon -> Cocoa
  • Next by Date: Re: Carbon -> Cocoa
  • Previous by thread: Re: Carbon -> Cocoa
  • Next by thread: Re: Carbon -> Cocoa
  • Index(es):
    • Date
    • Thread