Quoting Ben Lubar (2018-09-29 14:40:28) > [1]https://play.golang.org/p/iBAii-f84Sq > vet is complaining because the unsafe.Pointer usage would normally be > dangerous around the garbage collector, but since I have a finalizer on > the "real" pointer and there is no way the code could access the > uintptr with the same value as the real pointer once the finalizer has > run or been removed by Close, shouldn't this code be safe?
>From the unsafe package's documentation: > Even if a uintptr holds the address of some object, the garbage > collector will not update that uintptr's value if the object moves One valid implementation strategy for a garbage collector is to do arena allocation, and on a GC pass copy all *live* objects out of an arena into another one for longer-lived objects, and then free the old arena. In this case, your uintptrs would still still contain the old addresses, even though the objects have moved. Note that the finalizer is never run in this case, because the object has been moved without being garbage. Whether what you're doing is actually safe depends heavily on the implementation details of the garbage collector. It may or may not be possible for it to break given the current implementation; I don't know enough about it to be sure. But a correct implementation of the runtime could very well corrupt memory given the code you linked; even if it works now, it's possible in a future release of Go this could break. Hope this helps, -Ian -- 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.
