[swift-corelibs-dev] [libdispatch] DISPATCH_QUEUE_SERIAL & DISPATCH_QUEUE_CONCURRENT
Daniel Eggert
danieleggert at me.com
Wed Jan 20 14:58:53 CST 2016
> On 20 Jan 2016, at 21:36, Tony Parker <anthony.parker at apple.com> wrote:
>
> Hi Daniel,
>
>> On Jan 20, 2016, at 7:21 AM, Daniel Eggert <danieleggert at me.com> wrote:
>>
>> On 19 Jan 2016, at 18:56, Tony Parker <anthony.parker at apple.com> wrote:
>>>
>>> On Linux, I expect there to be no overlay. Instead we will just have a module map and swift files created by the dispatch project itself. This is what we do for Foundation, and it does require that stuff in the Darwin overlay is duplicated as part of the swift-corelibs-foundation project for Linux.
>>
>> Hi Tony,
>>
>> Could you elaborate a bit more on this works?
>>
>> I’d like to try to take a stab at adding Swift file(s) to swift-corelibs-libdispatch -- but I’m not sure how this would be done.
>>
>> /Daniel
>>
>
> For Foundation, we create a static library for the C portion of (this is CoreFoundation), then link it with the resulting dylib created from the Swift portion. The idea was that no one should use the C stuff directly. I’m not sure if this will work for dispatch - I haven’t tried it myself. We’re in very new territory here so I think we’ll have to experiment with a few things and see what works. I expect to find issues in clang’s support for this.
>
> - Tony
That makes sense. Might be difficult to pull off for libdispatch due to the build system it uses. But it would be good if we could use Swift for anything that’s related to blocks / closures.
I wonder if the current work to add libdispatch to the existing build system will make it easier to add something like this.
/Daniel
More information about the swift-corelibs-dev
mailing list