Bryan Matsuo wrote:
openldap-technical,
I am working on some Go (golang) bindings[1] for the LMDB library and I have some interest in exposing the functionality of mdb_set_compare (and mdb_set_dupsort). But it is proving difficult and I have a question about the function(s).
Calling mdb_set_compare from the Go runtime is challenging. Using C APIs with callbacks comes with restrictions[2][3]. I believe it impossible to bind these functions way that is flexible, as one would expect. A potential change to LMDB that would make binding drastically easier is having MDB_cmp_func to take a third "context" argument with type void*. Then a binding could safely use an arbitrary Go function for comparisons.
Is it possible for future versions of LMDB to add a third argument to the MDB_cmp_func signature? Otherwise would it be acceptable for a variant API to be added using a different function type, one accepting three arguments?
Thanks for the consideration.
Cheers,
- Bryan
[1] Go bindings -- https://github.com/bmatsuo/lmdb-go [2] Cgo pointer restrictions -- https://github.com/golang/proposal/blob/master/design/12416-cgo-pointers.md [3] Cgo documentation -- https://golang.org/cmd/cgo/
I see nothing in these restrictions that requires extra information to be passed from Go to C or from C to Go.
There is a vague mention in [2]
"A particular unsafe area is C code that wants to hold on to Go func and pointer values for future callbacks from C to Go. This works today but is not permitted by the invariant. It is hard to detect. One safe approach is: Go code that wants to preserve funcs/pointers stores them into a map indexed by an int. Go code calls the C code, passing the int, which the C code may store freely. When the C code wants to call into Go, it passes the int to a Go function that looks in the map and makes the call."
But it's nonsense in this case - you want to pass a Go function pointer to C, but the only way for C to use it is to call some *other* Go function? Sorry but there is no other Go function for the mdb_cmp() function to call, the only one it knows about is the function pointer that you pass.
If this is what you're referring to, adding a context pointer doesn't achieve anything. If this isn't what you're referring to, then please explain exactly what you hope to achieve with this context pointer.