[personZ]

The current state of the CGO interface is that you can't safely pass Go pointers to C code. That's all this document is repeating.

Where is this stated? Where is it said that it's technically incorrect?

Just to be clear, I'm not passing it and then running a thread in C that just runs with the pointer to an object that no longer exists in Go. Instead I'm calling a C function synchronously -- there is no possible way the element is going to be collected during that run. It could be compacted (though Go up until now has explicitly had a non-compacting GC, so not a current risk), of course, which is what brought up this issue, but that's the reason such interop languages have pinning (flagging that something shouldn't be moved).

It wasn't by chance -- it was by design, and it was purposefully understanding the lifetime of objects.

[ianlancetaylor]

There is a bit more background at http://golang.org/issue/8310.

The problem is that we hope to move toward a concurrent GC. That means that GC must be able to run concurrently with a long-running cgo call--otherwise a call to some C function that never returns for perfectly valid reasons will block GC forever. And when we have a concurrent moving GC, it is no longer possible to casually pass a Go pointer to C.

In other words, we want to make the Go garbage collector work much better for Go programs, and we don't want calling C to prevent that.

Although the actual plan is not nailed down, I suspect that we will permit passing a Go pointer to C as long as the memory to which that pointer points does not itself contain any Go pointers. The cgo interface will be permitted to either pin the pointer for the duration of the call, or to copy the data to a pinned memory area--your program won't know which will happen.

If you need something more complex to work, you will have to allocate the memory on the C side. It's always OK to pass C pointers to C.

[niemeyer]

That's a much more reasonable proposal than the prior suggestions of a strict no-Go-pointers-into-C rule, and it'll keep most interfaces working. Some C packages such as qml will still need to change as they allow custom types to travel through C and back into Go, and these pointers may move, but that's certainly not the common case.

[ominous_prime]

You're right, I can't find where it's explicitly forbidden in the docs, but it also isn't stated that you can pass pointers to C code either. There has been more recent discussion here (https://code.google.com/p/go/issues/detail?id=8310) and on the mailing lists too:

    > +rsc
    > Passing a Go pointer like that to C is problematic because eventually
    > we will want the garbage collector to be able to move things

and later on with a response from Dmitry:

    >> In my opinion, the current behavior should be covered by the 
    >> compatibility guarantee. In Go 1, passing pointers to Go-allocated 
    >> memory into C was not a problem. 
    >
    > This was never fully working. Only some individual cases were working.

Even though your C thread is being run synchronously, the GC is running concurrently in another thread (concurrent GC was introduced in go1.3), and has the ability to alter the memory that was passed to your C function.

[niemeyer]

The rule was never entirely clear, but there was definitely support towards allowing Go pointers to be visible in C code, as long as they were held referenced inside Go code somewhere. See this thread, for example:

https://code.google.com/p/go/issues/detail?id=6397#c11

That said, the rule is clearly changing now, and it is not even clear to what it is changing yet (see Ian's comment in this HN thread).

[pjmlp]

>Where is this stated? Where is it said that it's technically incorrect?

If I am not mistaken, it was discussed on the go-dev group.

Currently on the phone, cannot search properly for it.

EDIT: Now at home. This was the discussion thread

https://groups.google.com/forum/#!topic/golang-dev/pIuOcqAlv...