Fix runloop integration for libdispatch from swift

[ngrewe]

It seems like the runloop integration for the libdispatch main queue broke down a bit – unfortunately in a quite symmetrical way so that both the implementation and the tests would never be built, even if a compatible version of libdispatch existed (it was checking for HAVE_LIBDISPATCH_RUNLOOP where it should have been using GS_USE_LIBDISPATCH_RUNLOOP).

That uncovered a few problems with libdispatch from swift-corelibs. Our side of that is fixed here (simple typos, mostly), the libdispatch side of things is addressed in swiftlang/swift-corelibs-libdispatch#534.

I've also freshened up the Travis CI job a bit in the process so that this is continuously tested again.

[triplef]

The initial integration of the Swift libdispatch version was my work in #41, but it sounds like while it worked for us in the context of the Android toolchain it wasn’t quite up to par. Thank you for fixing it and especially also for the CI integration! Unlike the other libdispatch versions, the Swift one is being quite actively maintained, so this is great to see.

I was wondering if you could clarify swiftlang/swift-corelibs-libdispatch#534 when using the libobjc2 runtime. We’ve been using libBlocksRuntime from libdispatch, and as far as I can see libobjc2 does not include its own libBlocksRuntime. Where is the custom libBlocksRuntime defined and how does it differ from the one in libdispatch?

The one thing we noticed about ObjC interoperability was that libdispatch objects such as queues are not declared as ObjC types, so they e.g. can’t partake in ARC (OS_OBJECT_HAVE_OBJC_SUPPORT for us is 0).

[ngrewe]

far as I can see libobjc2 does not include its own libBlocksRuntime.

libobjc2 is the blocks runtime (even the first one, as David likes to say, since the relevant libobjc2 release was earlier than Apple managed to ship theirs, IIRC). So you just link libobjc2 and already get the runtime hooks required by the blocks ABI.

how does it differ from the one in libdispatch

Since blocks are also Objective-C objects they need some level of interoperability with Objective-C. The BlocksRuntime in libdispatch only interoperates with the Apple flavour of Objective-C (or not at all, unless you're building on Darwin, I suppose). The blocks runtime in libobjc2 (obviously) supports the GNUstep ABI.

The one thing we noticed about ObjC interoperability was that libdispatch objects such as queues are not declared as ObjC types, so they e.g. can’t partake in ARC (OS_OBJECT_HAVE_OBJC_SUPPORT for us is 0).

That mostly controls whether dispatch queues etc. also behave like ObjC objects and whether dispatch_data_t is toll-free bridged to NSData (nice!).
Unfortunately, looking at the implementation set off a brief psychotic episode for me. It's very tightly coupled with Apple's Objective-C ABI. It does fun things like manually creating vtables for classes and placing symbols into specific sections of the binary. There's also mention of some linker magic being required… I haven't yet given much sort to how to untangle all that.

[triplef]

Thank you @ngrewe, that’s very helpful info.

[fredkiefer]

Looks good to me.

[fredkiefer]

Should we update even further?

[ngrewe]

Of course, that makes sense. I was living in the past… and forgot that bionic is the newest Ubuntu LTS version.

[ngrewe]

Interestingly, that gives us some unrelated test failures for NSURL-related things 🤔. I guess I'll revert to xenial for the time being and investigate those independently....

[fredkiefer]

Wouldn't it be easier to keep this code here identical to the one in NSRunLoop.m?

[ngrewe]

In the implementation, we only need to call C functions from libdispatch, but in the test, we also need to schedule blocks onto the main queue to verify that running the runloop will drain the queue as well. Hence the subtle difference: The test code depends on a blocks capable compiler, the implementation code doesn't.

[fredkiefer]

Sorry, I was rather aiming at the lines below, not that one by itself.

[ngrewe]

Ah, got it: The HAVE_DISPATCH_H defines etc. come from Source/config.h, so it doesn't seem like they were supposed to be exposed to the test framework (otherwise it should be in a Headers/ subdirectory -- probably one of the reasons why this code path broke down with time). And since this is effectively a clang only code path, it made sense to do it using __has_include() here.

This is very defensive anyways: I haven't seen a build of libdispatch that didn't place its headers in subdirectory for a long time.

[fredkiefer]

I just merged your other pull request. If you update this one to the new master, I will merge it as well.