I’m trying to use libdispatch from Swift, but something is off with DISPATCH_QUEUE_SERIAL & DISPATCH_QUEUE_CONCURRENT:
func test() {
let queueA = dispatch_queue_create("a", DISPATCH_QUEUE_SERIAL)
let queueB = dispatch_queue_create("b", DISPATCH_QUEUE_CONCURRENT)
}
Dispatch.swift:81:45: error: cannot convert value of type '()' to expected argument type 'dispatch_queue_attr_t' (aka 'COpaquePointer')
let queueA = dispatch_queue_create("a", DISPATCH_QUEUE_SERIAL)
^~~~~~~~~~~~~~~~~~~~~
Dispatch.swift:82:45: error: use of unresolved identifier 'DISPATCH_QUEUE_CONCURRENT'
let queueB = dispatch_queue_create("b", DISPATCH_QUEUE_CONCURRENT)
^~~~~~~~~~~~~~~~~~~~~~~~~
From: Daniel Eggert via swift-corelibs-dev <swift-corelibs-dev@swift.org>
I’m trying to use libdispatch from Swift, but something is off with
DISPATCH_QUEUE_SERIAL & DISPATCH_QUEUE_CONCURRENT:
func test() {
let queueA = dispatch_queue_create("a", DISPATCH_QUEUE_SERIAL)
let queueB = dispatch_queue_create("b", DISPATCH_QUEUE_CONCURRENT)
}
Dispatch.swift:81:45: error: cannot convert value of type '()' to
expected argument type 'dispatch_queue_attr_t' (aka 'COpaquePointer')
let queueA = dispatch_queue_create("a", DISPATCH_QUEUE_SERIAL)
^~~~~~~~~~~~~~~~~~~~~
Dispatch.swift:82:45: error: use of unresolved identifier
'DISPATCH_QUEUE_CONCURRENT'
let queueB = dispatch_queue_create("b", DISPATCH_QUEUE_CONCURRENT)
^~~~~~~~~~~~~~~~~~~~~~~~~
Hi,
I believe the issue is that the definition of DISPATCH_QUEUE_SERIAL
and DISPATCH_QUEUE_CONCURRENT can't be processed by the Swift importer.
I responded in the bug but I will also respond here:
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.
The purpose of the overlay on Darwin is that we cannot yet ship Swift code as part of dispatch itself (since the standard library is shipped with each app as a static library). We don’t have that limitation on Linux.
- Tony
···
On Jan 19, 2016, at 5:38 AM, David P Grove via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
> From: Daniel Eggert via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>>
>
> I’m trying to use libdispatch from Swift, but something is off with
> DISPATCH_QUEUE_SERIAL & DISPATCH_QUEUE_CONCURRENT:
>
>
> func test() {
> let queueA = dispatch_queue_create("a", DISPATCH_QUEUE_SERIAL)
> let queueB = dispatch_queue_create("b", DISPATCH_QUEUE_CONCURRENT)
> }
>
>
>
> Dispatch.swift:81:45: error: cannot convert value of type '()' to
> expected argument type 'dispatch_queue_attr_t' (aka 'COpaquePointer')
> let queueA = dispatch_queue_create("a", DISPATCH_QUEUE_SERIAL)
> ^~~~~~~~~~~~~~~~~~~~~
> Dispatch.swift:82:45: error: use of unresolved identifier
> 'DISPATCH_QUEUE_CONCURRENT'
> let queueB = dispatch_queue_create("b", DISPATCH_QUEUE_CONCURRENT)
> ^~~~~~~~~~~~~~~~~~~~~~~~~
Hi,
I believe the issue is that the definition of DISPATCH_QUEUE_SERIAL and DISPATCH_QUEUE_CONCURRENT can't be processed by the Swift importer.
And having swift files created by the dispatch project itself would also solve the blocks issue -- those swift files could do native wrapping of the _f functions to re-create their block based counterparts. I added a comment to SR-577 that shows this. It would be a clean approach and allow for a a different blocks ABI on Linux -- something that’s apparently desired.
/Daniel
···
On 19 Jan 2016, at 18:56, Tony Parker <anthony.parker@apple.com> wrote:
Hi Dave, Daniel,
I responded in the bug but I will also respond here:
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.
The purpose of the overlay on Darwin is that we cannot yet ship Swift code as part of dispatch itself (since the standard library is shipped with each app as a static library). We don’t have that limitation on Linux.
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
···
On 19 Jan 2016, at 18:56, Tony Parker <anthony.parker@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.
On Jan 20, 2016, at 7:21 AM, Daniel Eggert <danieleggert@me.com> wrote:
On 19 Jan 2016, at 18:56, Tony Parker <anthony.parker@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.
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
···
On 20 Jan 2016, at 21:36, Tony Parker <anthony.parker@apple.com> wrote:
Hi Daniel,
On Jan 20, 2016, at 7:21 AM, Daniel Eggert <danieleggert@me.com> wrote:
On 19 Jan 2016, at 18:56, Tony Parker <anthony.parker@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.