0 Replies
      Latest reply on Apr 17, 2020 9:46 AM by d4ryl00
      d4ryl00 Level 1 Level 1 (0 points)



        I’m writing an Objective-C library that uses the MC (Multipeer Connectivity) framework. That library is compiled and integrated by the cgo command into an cli app written in Go. The main function (in Go) calls the library functions in a goroutine (new thread) and waits.


        I’m occurring a problem with the MC delegate callbacks that are never executed (at least MCNearbyServiceAdvertiser didReceiveInvitationFromPeer and MCNearbyServiceBrowser foundPeer). My tests let me suppose that these callbacks are sent to the main queue. However my main queue is not started because my app is not a Cocoa app.

        Furthermore I can’t start this main queue with dispatch_main() (if I try I get a SIGILL: illegal instruction) because my lib doesn't run on the main thread (also I can't put dispatch_main() in a block in a Dispatch Queue or Operation Queue because the main queue is stopped).


        My constraint: I have no access to the main thread in Go


        Below a sample code to reproduce the SIGILL:



        package main
        import "fmt"
        import "sync"
        #cgo CFLAGS: -x objective-c
        #cgo darwin LDFLAGS: -framework Foundation
        #include "driver.h"
        import "C"
        var wait sync.WaitGroup
        func main() {
                fmt.Println("main function")
                go C.enableQueue()
                go C.someStuff()



        #import "driver.h"
        void someStuff() {
        void enableQueue() {
                dispatch_async(dispatch_get_main_queue(), ^{
                        NSLog(@"dispatch_main() ok");



        void someStuff();
        void enableQueue();


        Compile with go build


        Do you have a trick to enable the main queue without having access to the main thread directly?

        Do you confirm that MC callbacks need the main queue?