Re: Carbon -> Cocoa

[Alastair Houghton]

On 22 Aug 2018, at 21:42, Saagar Jha  wrote:
> 
>> 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 
> 

On 23 Aug 2018, at 04:30, Uli Kusterer  wrote:
> 
> 
> I recall hearing from someone at Apple that they basically ported GCD to 
> Linux for the Swift Linux release ... have you looked whether that code might 
> give any clues about what may be happening on macOS?


Interesting. That isn’t quite the same libdispatch that’s used on the macOS by 
the look of things, but it does appear to have things merged across from the 
macOS version. It looks, from a cursory examination, as if the macOS 
functionality is built on top of a kernel “work queue” implementation that 
lives inside the non-open-source pthread.kext. (I’m sure I’m not the only one 
to have noticed that quite a bit of functionality has been moved from open 
source parts of the macOS to closed-source libraries and KEXTs; personally I 
find this a disappointing development, as it makes debugging and developing 
software harder if it’s impossible to inspect the source code.)

Anyway, from what I can see it seems highly unlikely that there will be any 
background threads to monitor file descriptors, at least on the macOS.

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

Re: Carbon -> Cocoa

[Alastair Houghton]

On 22 Aug 2018, at 19:32, Jens Alfke  wrote:
> 
>> On Aug 22, 2018, at 10:40 AM, Alastair Houghton 
>> 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