Add support for CFRunLoop integration APIs

[seabaylea]

Work has already been done by @kovpas and merged by @parkera to add a CFRunLoop implementation for Linux into CoreFoundation by PR #133 (swiftlang/swift-corelibs-foundation#133).

This followed the model in CFLite of using eventfd rather than mach ports, and calling the following two (new) APIs:

dispatch_get_main_queue_eventfd_np
dispatch_main_queue_drain_np

instead of the existing "4CF" calls:

_dispatch_get_main_queue_port_4CF
_dispatch_main_queue_callback_4CF

Those APIs don't exist in libdispatch, so this adds them. The APIs are defined in queue.h which effectively makes then public - that's been done because it matched the approach used by the CoreFoundation PR. If it makes sense to make them "4CF" functions I can modify the PR here and open an equivalent against CoreFoundation.

[MadCoder]

not ok to remove a comment that says something quite explicit about it not being removed ever.

[parkera]

This just moved up a few lines.

[MadCoder]

I disagree with that patch, I think it should not add new interfaces for the sake of linux when the _4CF things are just fine. If you diverge too much from the Mac OS X model you will have pain keeping in sync with our changes that keep iterating on how these interfaces work.

[MadCoder]

should be in "internal.h" and #ifdef

[MadCoder]

For the sake of porting I think the right way is like I said, have:

1. proper guards (suggested DISPATCH_ENABLE_RUNLOOP_SUPPORT)
2. same function names _4CF, which is not a lie, it's really about giving support to CFRunloop
3. abstract internally the "port" and its use away but do not touch _dispatch_main_queue_wakeup, only what it calls. The structure should completely be the same.

[seabaylea]

I'm happy to rename the guards and move to implementing _4CF functions.

As per my initial comment, I took the approach of implementing the interface functions as dispatch_get_main_queue_eventfd_np and dispatch_main_queue_drain_np because CoreFoundation/RunLoop.subproj/CFRunLoop.c had already been updated to use them.

Presumably we'll new some new _4CF functions for Linux as the consuming CFRunLoop code (currently) needs to know its receiving back a eventfd file descriptor rather than a "port".

[seabaylea]

@MadCoder I've made an interaction of changes that moves towards what your looking for - they're not complete but I'd like to get some feedback before doing much more.

For the CFRunLoop entry points, I've retained retained Linux specific APIs, but moved the declaration to queue_internal.h and renamed them as follows:

int dispatch_get_main_queue_eventfd_4CF()
void _dispatch_main_queue_drain_4CF()

The equivalents for Darwin and Windows return a "port"/Handle, and the "drain" function for Darwin has the port as a parameter. Using shared _4CF functions could be achieved but would require a sizeable refactoring of the interface between CFRunLoop and libdispatch. CFRunLoop currently handles the fact that it it working with a port/Handle/eventfd for notifications whereas that would all have to be pushed down to libdispatch.
Does this seem reasonable for now? Should the definitions be moved from queue_internal.h to private.h?

I've introduced a new DISPATCH_ENABLE_RUNLOOP_SUPPORT guard, but had to retain the use of DISPATCH_COCOA_COMPAT and DISPATCH_LINUX_COMPAT for the Darwin/Windows and Linux specific sections. I'm not sure if this is the best approach - and feedback is appreciated.

I've also left the implementation of pthread_main_np as-is for the moment, as that's dependent on PR #44 which isn't yet merged.

[seabaylea]

Hi @MadCoder . Can you take a second look at this and give some recommendations on how we can move forward?

[seabaylea]

Hi @MadCoder . Have you been able to do another review of this yet?

[MadCoder]

Replaced by #101