Go 1.6 is more strict: cgo argument has Go pointer to Go pointer

[emicklei]

Today, at FOSDEM in Brussel, I learned about a new compiler change regarding the use of pointers in cgo. Wondering if this would affect v8worker, I tried building the project using 1.6rc1. I hope we can find a way to play by the new rules.

panic: runtime error: cgo argument has Go pointer to Go pointer [recovered]
    panic: runtime error: cgo argument has Go pointer to Go pointer

goroutine 5 [running]:
testing.tRunner.func1(0xc820090000)
    /usr/local/go/src/testing/testing.go:467 +0x192
github.com/ry/v8worker._cgoCheckPointer0(0xb80740, 0xc82000a140, 0x0, 0x0, 0x0, 0x0)
    github.com/ry/v8worker/_obj/_cgo_gotypes.go:58 +0x4d
github.com/ry/v8worker.New(0xc8200105b0, 0xc8200105c0, 0xc820012390)
    /go/src/github.com/ry/v8worker/worker.go:70 +0xe2
bitbucket.org/emicklei/v8dispatcher.NewMessageDispatcher(0x0)
    /go/src/bitbucket.org/emicklei/v8dispatcher/dispatcher.go:34 +0x18c

[emicklei]

Actually, this output is from running the tests of v8dispatcher (that uses v8worker). I will try a build of v8worker now.

[emicklei]

Some discussions around this topic https://groups.google.com/forum/#!searchin/golang-nuts/cgo$20argument$20has$20Go$20pointer$20to$20Go$20pointer/golang-nuts/gnH0nhPf36I/4Shly3gxEwAJ which refers to golang/go#12416

[emicklei]

As described in the previous discussions (see links), a workaround is to use GODEBUG=cgocheck=0

[ry]

I guess this is caused by storing a pointer to the Go worker object in the data field of the C worker object.

v8worker/worker.go

Line 70 in a2fb65d

worker.cWorker = C.worker_new(callback, receiveSync_callback, unsafe.Pointer(worker))

We don't need to do this - the data object is opaque to the C code. We could use some sort of look up table in the golang side to store all the workers and just send a key (an integer?) to the C code. I'll try to do this now.. writing this out in case I get distracted and don't finish.

[emicklei]

I was thinking about putting the callbacks in some registry to avoid having pointer values inside the worker struct (the map-registry approach as mentioned in the issue).
Your suggestion sounds much simpler.