Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You can call Go code from C. it is a confusing proposition though. </p> <p>The process is outlined in the blog post you linked to. But I can see how that isn't very helpful. Here is a short snippet without any unnecessary bits. It should make things a little clearer.</p> <pre><code>package foo // extern int goCallbackHandler(int, int); // // static int doAdd(int a, int b) { // return goCallbackHandler(a, b); // } import "C" //export goCallbackHandler func goCallbackHandler(a, b C.int) C.int { return a + b } // This is the public function, callable from outside this package. // It forwards the parameters to C.doAdd(), which in turn forwards // them back to goCallbackHandler(). This one performs the addition // and yields the result. func MyAdd(a, b int) int { return int( C.doAdd( C.int(a), C.int(b)) ) } </code></pre> <p>The order in which everything is called is as follows:</p> <pre><code>foo.MyAdd(a, b) -&gt; C.doAdd(a, b) -&gt; C.goCallbackHandler(a, b) -&gt; foo.goCallbackHandler(a, b) </code></pre> <p>The key to remember here is that a callback function must be marked with the <code>//export</code> comment on the Go side and as <code>extern</code> on the C side. This means that any callback you wish to use, must be defined inside your package. </p> <p>In order to allow a user of your package to supply a custom callback function, we use the exact same approach as above, but we supply the user's custom handler (which is just a regular Go function) as a parameter that is passed onto the C side as <code>void*</code>. It is then received by the callbackhandler in our package and called.</p> <p>Let's use a more advanced example I am currently working with. In this case, we have a C function that performs a pretty heavy task: It reads a list of files from a USB device. This can take a while, so we want our app to be notified of its progress. We can do this by passing in a function pointer that we defined in our program. It simply displays some progress info to the user whenever it gets called. Since it has a well known signature, we can assign it its own type:</p> <pre><code>type ProgressHandler func(current, total uint64, userdata interface{}) int </code></pre> <p>This handler takes some progress info (current number of files received and total number of files) along with an interface{} value which can hold anything the user needs it to hold.</p> <p>Now we need to write the C and Go plumbing to allow us to use this handler. Luckily the C function I wish to call from the library allows us to pass in a userdata struct of type <code>void*</code>. This means it can hold whatever we want it to hold, no questions asked and we will get it back into the Go world as-is. To make all this work, we do not call the library function from Go directly, but we create a C wrapper for it which we will name <code>goGetFiles()</code>. It is this wrapper that actually supplies our Go callback to the C library, along with a userdata object.</p> <pre><code>package foo // #include &lt;somelib.h&gt; // extern int goProgressCB(uint64_t current, uint64_t total, void* userdata); // // static int goGetFiles(some_t* handle, void* userdata) { // return somelib_get_files(handle, goProgressCB, userdata); // } import "C" import "unsafe" </code></pre> <p>Note that the <code>goGetFiles()</code> function does not take any function pointers for callbacks as parameters. Instead, the callback that our user has supplied is packed in a custom struct that holds both that handler and the user's own userdata value. We pass this into <code>goGetFiles()</code> as the userdata parameter.</p> <pre><code>// This defines the signature of our user's progress handler, type ProgressHandler func(current, total uint64, userdata interface{}) int // This is an internal type which will pack the users callback function and userdata. // It is an instance of this type that we will actually be sending to the C code. type progressRequest struct { f ProgressHandler // The user's function pointer d interface{} // The user's userdata. } //export goProgressCB func goProgressCB(current, total C.uint64_t, userdata unsafe.Pointer) C.int { // This is the function called from the C world by our expensive // C.somelib_get_files() function. The userdata value contains an instance // of *progressRequest, We unpack it and use it's values to call the // actual function that our user supplied. req := (*progressRequest)(userdata) // Call req.f with our parameters and the user's own userdata value. return C.int( req.f( uint64(current), uint64(total), req.d ) ) } // This is our public function, which is called by the user and // takes a handle to something our C lib needs, a function pointer // and optionally some user defined data structure. Whatever it may be. func GetFiles(h *Handle, pf ProgressFunc, userdata interface{}) int { // Instead of calling the external C library directly, we call our C wrapper. // We pass it the handle and an instance of progressRequest. req := unsafe.Pointer(&amp;progressequest{ pf, userdata }) return int(C.goGetFiles( (*C.some_t)(h), req )) } </code></pre> <p>That's it for our C bindings. The user's code is now very straight forward:</p> <pre><code>package main import ( "foo" "fmt" ) func main() { handle := SomeInitStuff() // We call GetFiles. Pass it our progress handler and some // arbitrary userdata (could just as well be nil). ret := foo.GetFiles( handle, myProgress, "Callbacks rock!" ) .... } // This is our progress handler. Do something useful like display. // progress percentage. func myProgress(current, total uint64, userdata interface{}) int { fc := float64(current) ft := float64(total) * 0.01 // print how far along we are. // eg: 500 / 1000 (50.00%) // For good measure, prefix it with our userdata value, which // we supplied as "Callbacks rock!". fmt.Printf("%s: %d / %d (%3.2f%%)\n", userdata.(string), current, total, fc / ft) return 0 } </code></pre> <p>This all looks a lot more complicated than it is. The call order has not changed as opposed to our previous example, but we get two extra calls at the end of the chain:</p> <p>The order is as follows:</p> <pre><code>foo.GetFiles(....) -&gt; C.goGetFiles(...) -&gt; C.somelib_get_files(..) -&gt; C.goProgressCB(...) -&gt; foo.goProgressCB(...) -&gt; main.myProgress(...) </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POCall Go functions from C
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USjimt
    1. USjimt
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POCall Go functions from C
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COYes, I do realize that all this may blow up in our faces when separate threads come into play. Specifically those not created by Go. Unfortunately that is the way things are at this point.
      singulars
      1. PO
      1. USjimt
    2. COThis is a really good answer, and thorough. It doesn't directly answer the question, but that is because there is no answer. According to several sources, the entry point has to be Go, and cannot be C. I'm marking this as correct because this really cleared stuff up for me. Thanks!
      singulars
      1. PO
      1. UStjameson
    3. CO@jimt How does that integrate with the garbage collector? Specifically, when is the private progressRequest instance collected, if ever? (New to Go, and thus to unsafe.Pointer). Also, what about API like SQLite3 that take a void* userdata, but also an optional "deleter" function for userdata? Can that be used to interact with the GC, to tell it "now it's OK to reclaim that userdata, provided the Go side doesn't reference it anymore?".
      singulars
      1. PO
      1. USddevienne
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload