Golang object destructor for C/C++ bindings

Getting Help
1

We are building cryptorgraphic libraries with C/C++, and now adding also Golang support for it.
CGO binding works fine except one thing We need to call some function to free C pointers from memory manually.
Currently we are doing like this, by making some Go interface wrapper for cleaning up memory.

func SomeFunc() {
  cObj := NewObjectFromCPP()
  defer cObj.Free()
}

We also tried to use runtime.SetFinilizer to clean memory when Golang GC trying to clean wrapped object. BUT it turns out that runtime.SetFinilizer callback not running very time, or not running at all, because in documentation it says it will run eventually.

Our current solution is hacky from my point of view, and wanted to get some input from people who already done something like this.

What is the right way of cleaning C/C++ memory from Go besides directly calling manual methods?

2

According to my understanding of the english language, “eventually” means, that it will happen, but it can take a very long time until it actually happens.

“He eventually arrives” doe not mean “Maybe he will arrive” but “He is comming, but I’m not sure when he’ll arrive”.

I can’t say so if the author of your document had the same understanding of “eventually” as me (and my dictionary [google for definition of eventually]):

eventually
/ɪˈvɛntʃʊ(ə)li/

adverb
in the end, especially after a long delay, dispute, or series of problems.
“eventually, after midnight, I arrived at the hotel”
synonyms: in the end, in due course, by and by, in time, after some time, after a period of time, after a long time, after a bit, finally, at last, at long last; ultimately, in the long run, in the fullness of time, at some point in the future, at a future date, at the end of the day, one day, one of these fine days, some day, sometime, in time to come, sooner or later, when all is said and done
“eventually we arrived at a small town”

So I have to ask, have you actually tested if destructors are run properly?

3

I’m with Norbert on this, the defer action will take place when the function scope the defer was declared in exits. You can rely on that to happen, but stepping over the program would let you know for sure.

4

You are correct “eventually” means it will happen, but it might take a lot of time.
First implementation of our library was using runtime.SetFinilizer, and we’ve been relaying on that, BUT sometimes on very heavy usage, memory started to grow few GB’s and it was taking 3-4 hours to clean up and run Finalizers, which is not an option for having API endpoint or any other long running application.

That’s why we started to use defer instead, and now just cleaning memory manually, which is very annoying, but it works fine in terms of an execution.

So my question was, is there any other way similar to runtime.SetFinilizer but with more predictable callbacks?
Thanks

5

I found this guy’s notes on the subject of memory management (which echo your own experience with runtime.SetFinilizer ) with cgo and it might shed some light on how to use the defer method in predictable ways: https://gist.github.com/dwbuiten/c9865c4afb38f482702e

Basically defer calls are last in first out

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.