I have this struct that has an associated method that simply call a C
function that might take a long time to use. It is defined more or less
like this:
import "C"
type Indexer struct {
cIndexer *C.Indexer
}
func NewIndexer() *Indexer {
i := &Indexer{getCIndexerPointer()}
runtime.SetFinalizer(i, (*Indexer).finalize)
}
func (i *Indexer) finalize() {
freeCIndexertPointer(i.cIndexer)
}
func (i *Indexer) Commit() {
callCCommit(i.cIndexer)
}
Then I have some code that uses an indexer object:
func Index() {
i := NewIndexer()
// Index documents calling Indexer methods.
i.Commit()
}
For some corpus, the Commit() call above might take several minutes to
complete. It looks like that if the garbage collector kicks in when it is
running, the runtime thinks that it is ok to collect the object and this
triggers the finalizer that, in turn, deletes the internal C object that,
finally, make the C commit call to crash as the C struct it uses to do its
job was freed.
I am aware that a call to runtime.KeepAlive(i) after the Commit() call
should be enough to sort this up, but I am wondering why it is required at
all in this case. Isn't the fact that a method on a struct type is running
enough to avoid collection? If not, shouldn't it be? Or is this related to
the usage of CGO?
In any case, it was a bit unexpected to me (although I did guess that the
problem was this and adding debug to the finalizer helped confirming it). I
would go as far as to say this looks like a bug.
Thoughts?
--
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.
