Ian's advice seems sound. But there is one other option to consider. When 
practical, I like to simply copy C allocated memory to Go allocated memory 
in the wrapper for the cgo call, and free the C memory immediately. This 
removes the insanity of keeping track of C memory in Go. Obviously there 
are myriad reasons why this might not be possible, or might impose to great 
a penalty. But where it is possible, it makes life easy again. 

On Friday, November 1, 2019 at 9:28:36 AM UTC-4, Tom Payne wrote:
> cgo is often used to provide bindings to C libraries. Any memory allocated 
> in the C library is not visible to Go, so Go does not have an accurate view 
> of the program's memory usage and does not run the garbage collector or any 
> finalizers often enough. Consequently, memory usage for a Go server that 
> uses cgo heavily can grow very large, with Go itself being utterly unaware 
> of it.
> If the C functions allocate memory, historically you could set a finalizer 
> to free the memory sometime after there are no remaining references to it 
> in Go, as, for example, described in this blog post 
> <http://rabarar.github.io/blog/2015/09/29/cgo-and-destructors-for-managing-allocated-memory-in-go/>.
> However, the current Go docs on runtime.SetFinalizer 
> <https://golang.org/pkg/runtime/#SetFinalizer> state:
> > There is no guarantee that finalizers will run before a program exits, 
> so typically they are useful only for releasing non-memory resources 
> associated with an object during a long-running program.
> Are there any other ways to automatically release memory resources 
> associated with an object? Or telling Go's memory manager that the small 
> object it sees in the Go world is but the tip of an iceberg of memory 
> allocated in the C world and therefore should be finalized?
> Not-good options include:
> - Requiring the programmer to make explicit calls to free the memory 
> resources when they believe the object is no longer needed, but this takes 
> us back to the painful world of C's manual memory management and is easy to 
> get wrong.
> - Padding Go objects associated with C memory resources with large, unused 
> fields (e.g. an [1024]byte) in the hope that the Go garbage collector will 
> be more likely to finalize and free them when they are unused.
> - Avoiding cgo in any server code.
> Are there any good options?
> Cheers,
> Tom

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 

Reply via email to