Thank you very much, Ian.

Regards
– Bhaskar

On Wednesday, July 3, 2019 at 5:44:58 PM UTC-4, Ian Lance Taylor wrote:
>
> On Wed, Jul 3, 2019 at 1:32 PM K.S. Bhaskar <ksbh...@gmail.com 
> <javascript:>> wrote: 
> > 
> > https://github.com/golang/go/issues/13347#issuecomment-158568326 seems 
> to suggest runtime.KeepAlive() is not needed but it does not seem 
> definitive. 
> > 
> > If there is a function such as the one below (from 
> https://gitlab.com/YottaDB/Lang/YDBGo/blob/47f5960d03b2c00ae33222ec1d3bdc60a98226c1/buffer_t.go#L151)
>  
> in an application that has Go structures with pointers to C structures and 
> which uses Finalizers to free the C structures when the Go structures are 
> collected, is the runtime.KeepAlive(ibuft) required to guarantee that ibuft 
> is never collected by the Go garbage collector until after the return from 
> Free()? 
> > 
> > // Calls C.free on any C memory owned by this internalBuffer 
> > 
> > func (ibuft *internalBufferT) Free() { 
> > 
> >         printEntry("internalBufferT.Free()") 
> > 
> >         if nil == ibuft { 
> > 
> >                return 
> > 
> >         } 
> > 
> >         cbuftptr := ibuft.cbuft 
> > 
> >         if nil != cbuftptr { 
> > 
> >                // ydb_buffer_t block exists - free its buffer first if 
> it exists 
> > 
> >                if nil != cbuftptr.buf_addr { 
> > 
> >                        C.free(unsafe.Pointer(cbuftptr.buf_addr)) 
> > 
> >                } 
> > 
> >                C.free(unsafe.Pointer(cbuftptr)) 
> > 
> >                ibuft.cbuft = nil 
> > 
> >         } 
> > 
> >         runtime.KeepAlive(ibuft) 
>
> In the exact code I don't think the runtime.KeepAlive is needed, 
> because the assignment "ibuft.cbuft = nil" should keep ibuft alive. 
>
> But if I were writing that code I would definitely write the 
> runtime.KeepAlive.  Follow a simple rule: if you use 
> runtime.SetFinalizer on instances of a type, then always use 
> runtime.KeepAlive in every method of that type.  It costs you 
> essentially nothing and may save your program from memory corruption. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7de41346-cc17-4263-a4f5-ae94ec85778b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to