On 22 Aug 2018, at 17:53, Jens Alfke <j...@mooseyard.com> wrote: > >> On Aug 21, 2018, at 8:33 AM, Alastair Houghton <alast...@alastairs-place.net >> <mailto:alast...@alastairs-place.net>> 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; 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 (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
