On 22 Aug 2018, at 19:32, Jens Alfke <j...@mooseyard.com> wrote: > >> On Aug 22, 2018, at 10:40 AM, Alastair Houghton >> <alast...@alastairs-place.net <mailto:alast...@alastairs-place.net>> 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 (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
