Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SR-577] Compiler should pass -Xcc -fblocks when processing .h files #43194

Closed
swift-ci opened this issue Jan 18, 2016 · 4 comments
Closed

[SR-577] Compiler should pass -Xcc -fblocks when processing .h files #43194

swift-ci opened this issue Jan 18, 2016 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-577
Radar None
Original Reporter deggert (JIRA User)
Type Bug
Status Resolved
Resolution Duplicate
Environment

swift-2.2-SNAPSHOT-2016-01-11-a-ubuntu15.10

% uname -a
Linux ubuntu 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Additional Detail from JIRA
Votes 0
Component/s
Labels Bug
Assignee None
Priority Medium

md5: 725f7ac2dd6335a0f444849544c7c699

duplicates:

  • SR-397 Linux - module using <dispatch/dispatch.h> does not compile cleanly with "swift build"

Issue Description:

I’ve create a system module for libdispatch, but when I import it, I don’t see anything guarded by BLOCKS because the compiler doesn't pass -Xcc -fblocks.

% cat Package.swift 
import PackageDescription
let package = Package(name: "CDispatch”)


% cat module.modulemap 
module CDispatch [system] {
umbrella header "/usr/local/include/dispatch/dispatch.h"
link "dispatch"
export *
}


% uname -a
Linux ubuntu 4.2.0-16-generic #&#8203;19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux



% swift -I path/to/CDispatch-1.0.2
Welcome to Swift version 2.2-dev (LLVM 3ebdbb2c7e, Clang f66c5bb67b, Swift 1f2908b4f7). Type :help for assistance.
1> import CDispatch
2> dispatch_group_
Available completions:
    dispatch_group_async_f(group: dispatch_group_t, queue: dispatch_queue_t, context: UnsafeMutablePointer<Void>, work: dispatch_function_t(UnsafeMutablePointer<Void>) -> Void) -> Void
    dispatch_group_create() -> dispatch_group_t
    dispatch_group_enter(group: dispatch_group_t) -> Void
    dispatch_group_leave(group: dispatch_group_t) -> Void
    dispatch_group_notify_f(group: dispatch_group_t, queue: dispatch_queue_t, context: UnsafeMutablePointer<Void>, work: dispatch_function_t(UnsafeMutablePointer<Void>) -> Void) -> Void
    dispatch_group_t
    dispatch_group_wait(group: dispatch_group_t, timeout: dispatch_time_t) -> Int
@swift-ci
Copy link
Collaborator Author

Comment by Daniel Eggert (JIRA)

I worked around this by using the _f version of the functions and wrapping the blocks like so:

private func dispatch_async(queue: dispatch_queue_t, _ block: Block) {
    dispatch_async_f(queue, BlockCopy(block), callBlockAndRelease)
}



public typealias Block = @convention(block) () -> Void

private final class BlockBox<A> {
    let block: A
    init(_ block: A) {
        self.block = block
    }
}
private func BlockCopy<A>(block: A) -> UnsafeMutablePointer<Void> {
    let opaque = Unmanaged.passRetained(BlockBox(block)).toOpaque()
    return UnsafeMutablePointer<Void>(opaque)
}
private let callBlockAndRelease: @convention(c) (UnsafeMutablePointer<Void>) -> () = { (pointer: UnsafeMutablePointer<Void>) -> () in
    let unmanaged = Unmanaged<BlockBox<Block>>.fromOpaque(COpaquePointer(pointer))
    unmanaged.takeRetainedValue().block()
}

@zwaldowski
Copy link

That's brilliant. Isn't `@convention(block)` compatible with `void *`? Could `_Block_copy` be used without RR and without the Swift box?

@swift-ci
Copy link
Collaborator Author

Comment by Daniel Eggert (JIRA)

This code moves the block to the heap. The retain-release overhead here is probably even less that on OS X (where it’s an ObjC RR). Another option would be to use raw memory by means of an UnsafeMutablePointer. I don't know enough about the implementation details to say what the performance impact would be, though. Either way it's negligible in my opinion.

@zwaldowski
Copy link

Right, sorry, let me clarify: I meant "without RR" as "without the block ABI changes indicated on the mailing list".

The cost of the extra box is neither here nor there, I just think it'd be prudent to avoid if we didn't have to. But that's irrelevant to the larger point which is "OMG cool workaround!". 🙂

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@zwaldowski @swift-ci