On Mon, Feb 19, 2018 at 8:35 PM Eric Woroshow <eric.woros...@gmail.com>
> Using uintptr might work, but my concern is that passing a Go pointer
into C by way of a uintptr value might confuse the GC (specifically, that
the memory would fail to be pinned if/when Go implements a moving GC).
Uintptr is an integer type like any other. The GC does not care about
integer values. However, the concern about Go objects being moved is valid
as the Go compiler already does that in certain cases (stack allocs, but
it's not specified when they occur) and, IIRC, pins only unsafe.Pointers
passed to the CGO call. In such scenarios it might be possible to use a
custom memory allocator to guarantee the stability of the
passed-via-uintptr address. Or one can simply use C.malloc, provided the
CGO call overhead is not prohibitive. In both cases, there's another
possible problem: the out-of-Go-runtime-control allocated Go object cannot
contain pointers to any Go-runtime-controlled Go objects as those pointers
will not be updated when the pointees are eventually moved (credit Ian
Taylor for this valuable notice).
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.