cgo callbacks

[Ian Lance Taylor]

I've added a new facility to the cgo program: you can now mark a Go
function as callable from C. To do this, write a comment

//export NAME

as part of the comments which appear immediately before the function.
Your C code can then call the function under the specified name.

When any //export comments appear in the cgo input, cgo will create
two new files: _cgo_export.h and _cgo_export.c. The .h file declares
the Go functions in C syntax, and the intent is that your C code will
#include it in order to see the declarations that it can call. The
_cgo_export.c file contains the function wrappers; the file must be
compiled with gcc and linked with your C code.

There is an example in misc/cgo/life.

I implemented this as part of my ongoing work adding support for Go to
SWIG. Implementing SWIG's director feature requires the ability to
call back from C/C++ to Go, so I wrote that. I added support to cgo
in order to test the new feature.

Ian

[Ostsol]

On Apr 9, 3:45 pm, Ian Lance Taylor <i...@google.com> wrote:
> When any //export comments appear in the cgo input, cgo will create
> two new files: _cgo_export.h and _cgo_export.c.  The .h file declares
> the Go functions in C syntax, and the intent is that your C code will
> #include it in order to see the declarations that it can call.  The
> _cgo_export.c file contains the function wrappers; the file must be
> compiled with gcc and linked with your C code.

So this means that one cannot simply pass a pointer to a Go function
to C? Based on this I wrote a test program that involved a wrapper
written in C (and using the new export functionality), that is passed
to a C function in another library, all of which is called via a
function defined in the comments above 'import "C"':

package callback

// #include "callgo.h"
// #include "funcwrap.h"
// void _call_go_add() {
// call_go(&wrap_GoAdd);
// }
import "C"

func Run() {
C._call_go_add()
}

//export GoAdd
func GoAdd(a, b int) int {
return a + b
}

Quite cumbersome. . . Will we be able to pass a Go function directly
in the future?

-Daniel

[Ian Lance Taylor]

Ostsol <ost...@gmail.com> writes:

> On Apr 9, 3:45 pm, Ian Lance Taylor <i...@google.com> wrote:
>> When any //export comments appear in the cgo input, cgo will create
>> two new files: _cgo_export.h and _cgo_export.c.  The .h file declares
>> the Go functions in C syntax, and the intent is that your C code will
>> #include it in order to see the declarations that it can call.  The
>> _cgo_export.c file contains the function wrappers; the file must be
>> compiled with gcc and linked with your C code.
>
> So this means that one cannot simply pass a pointer to a Go function
> to C?

That is correct.

> Quite cumbersome. . . Will we be able to pass a Go function directly
> in the future?

6g/8g and gcc use different calling conventions and the functions run
on different stacks. That means that passing a function pointer
either from Go to C or from C to Go will always require wrapping at
some level. It's possible that cgo could be taught to create that
wrapping automatically. I don't plan to work on that myself, but it
could be an interesting project for somebody else.

Ian

[Tony Worm]

Is this still the convention for callbacks from C to Go

for example I need to pass function pointers to a nonlinear least squares solver:

extern int dlevmar_der(

      void (*func)(double *p, double *hx, int m, int n, void *adata),

      void (*jacf)(double *p, double *j, int m, int n, void *adata),

      double *p, double *x, int m, int n, int itmax, double *opts,

      double *info, double *work, double *covar, void *adata);

 /* Rosenbrock function */

    m=2; n=2;

    p[0]=-1.2; p[1]=1.0;

    for(i=0; i<n; i++) x[i]=0.0;

    ret=dlevmar_der(ros, jacros, p, x, m, n, 1000, opts, info, NULL, NULL, NULL); // with analytic Jacobian

these are where I'd like to call Go functions: (for analytic expression evaluation on some data points)

void ros(double *p, double *x, int m, int n, void *data)

{

register int i;

  for(i=0; i<n; ++i)

    x[i]=((1.0-p[0])*(1.0-p[0]) + ROSD*(p[1]-p[0]*p[0])*(p[1]-p[0]*p[0]));

}

void jacros(double *p, double *jac, int m, int n, void *data)

{

register int i, j;

  for(i=j=0; i<n; ++i){

    jac[j++]=(-2 + 2*p[0]-4*ROSD*(p[1]-p[0]*p[0])*p[0]);

    jac[j++]=(2*ROSD*(p[1]-p[0]*p[0]));

  }

}

On Monday, April 12, 2010 12:57:15 PM UTC-4, Ian Lance Taylor wrote:

Ostsol writes:

> On Apr 9, 3:45 pm, Ian Lance Taylor wrote:

[Kyle Lemons]

You can //export a Go function to be callable from C, and these can be used in callbacks that run from a go-owned thread.  Be aware that these function calls can be something like 50x slower than a normal function call last time I benchmarked.

[Tony Worm]

would this 50x be just for the callback?

I am thinking of something like the comparison of the following:

big_loop {

    data[i] = callback()

}

versus

callback() {

  big_loop {

     data = eval()

  }

}

On Monday, June 11, 2012 5:57:29 PM UTC-4, Kyle Lemons wrote:

You can //export a Go function to be callable from C, and these can be used in callbacks that run from a go-owned thread.  Be aware that these function calls can be something like 50x slower than a normal function call last time I benchmarked.

[Kyle Lemons]

When you call from C into Go, there's a lot of work that goes on in the runtime (from my understanding) beyond simply jumping to a new location in memory.  The overhead is for the function call from C into Go.

On Mon, Jun 11, 2012 at 3:08 PM, Tony Worm <verd...@gmail.com> wrote:

would this 50x be just for the callback?

I am thinking of something like the comparison of the following:

big_loop {

    data[i] = callback()

}

versus

callback() {

  big_loop {

     data = eval()

  }

}

The second would do a lot to amortize the cost of the callback, yes.