On Mon, Feb 19, 2018 at 8:35 PM Eric Woroshow <eric.woros...@gmail.com> wrote:
> 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). -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
