On Saturday, September 29, 2018 at 2:49:19 PM UTC-5, Ian Denhardt wrote: > > 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 >
Is there any way to implement this safely, or should I just give up on the weak pointer idea? -- 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.
