[swift-corelibs-dev] libdispatch build issue

[Pierre Habouzit]

> On Dec 11, 2015, at 9:57 AM, Pierre Habouzit via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> 
>> 
>> On Dec 11, 2015, at 9:02 AM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>> wrote:
>> 
>> This is only tangentially related: but I was attempting to build dispatch as well to start work on CFRunLoop and a few other dispatch bound features in Foundation on linux. I was seeing similar failures as Dzianis Fedarenka. Is there a branch/fork that I can grab to test this stuff out w/ bringing stuff up in Foundation?
>> 
>> My question is that of design and status of where things are at; CFRunLoop requires a method to interoperate with the main dispatch queue via _dispatch_get_main_queue_port_4CF and _dispatch_main_queue_callback_4CF. CFRunLoop will need to transact upon the same event source type as dispatch to ensure the main queue behaves correctly - so what type of event source should we be using? A socket? A producer/consumer notification via pthread conditions?
> 
> The linux equivalent to what we’re doing for the runloop is to use an eventfd() to replace sending messages to its port.

Though the runloop code should be disabled on linux right now, as it’s highly dependent on mach ports, and we should discuss whether having a dispatch queue attached to the runloop makes sense for the non mach version, and if it does, should it have exactly the same queue_runloop implementation as today. I think not, and the simplest way to port the implementation is to have a different implementation for linux completely and not rely on the weird 4CF hooks that we have on OS X.

-Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151211/c51ea10f/attachment.html>