Re: Carbon -> Cocoa
Re: Carbon -> Cocoa
- Subject: Re: Carbon -> Cocoa
- From: Saagar Jha <email@hidden>
- Date: Wed, 22 Aug 2018 13:42:46 -0700
Sent from my iPhone
> On Aug 22, 2018, at 10:40, Alastair Houghton <email@hidden>
> wrote:
>
>> On 22 Aug 2018, at 17:53, Jens Alfke <email@hidden> wrote:
>>
>>> On Aug 21, 2018, at 8:33 AM, Alastair Houghton
>>> <email@hidden <mailto:email@hidden>> wrote:
>>>
>>> So, for instance, it’s not so good on macOS or iOS if its event dispatcher
>>> is based on select(), (e)poll() or kqueue() because what you really want on
>>> macOS/iOS is for the event dispatch to go via CFRunLoop; if it doesn’t,
>>> you’ll end up having to use threading to run the network library’s event
>>> loops on background threads, which for an async networking library kind of
>>> defeats the point IMO.
>>
>> It does mean you have to spin up one background thread to sit and wait for
>> events; but that's not a big hardship. You still get the scalability
>> benefits of event-driven I/O, vs. having to use one thread per socket the
>> old-fashioned way.
>
> 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 as you’ll need to forward to the main thread and it
> may in some cases for you to use synchronisation when you wouldn’t have
> needed to. 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.
>
>> (NSURLSession and Network.framework are doing the same thing under the hood,
>> after all.)
>
> Are they? kqueue() supports monitoring of fds, Mach ports and timers, so
> there’s really no reason that CFRunLoop would have to spawn a background
> thread just to monitor some file descriptors. As far as I can tell, the
> current CFRunLoop implementation is built on top of GCD, which sadly we don’t
> have the source code for
libdispatch is open source: https://github.com/apple/swift-corelibs-libdispatch
> ; I don’t have time to reverse engineer it right now to see whether or not
> GCD does in fact spawn background thread(s) for this or not, but I see no
> particular reason it should have to.
>
> 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
_______________________________________________
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