How should I write the .i file to wrap callbacks in Java or C#

Question

My C program uses callback functions which are periodically called. I want to be able to handle the callback functions in a Java or C# program. How should I write the .i fil

Answer 1

C# solution : you must use delegates. look at the code sample

public delegate void DoSome(object sender);

public class MyClass{
      public event DoSome callbackfunc;

      public void DoWork(){
            // do work here 
            if(callbackfunc != null)
                     callbackfunc(something);
      }
}

this is also like event handling mechanism but by theory both of have same implementation in c#

Java solution: you must use interfaces, look at this sample code

interface Notification{
      public void somthingHappend(Object obj);
}

class MyClass{
     private Notification iNotifer;

     public void setNotificationReciver(Notification in){
            this.iNotifier = in;
     }

     public void doWork(){
            //some work to do
            if(something heppens){ iNotifier.somthingHappend(something);}
     }
}

actually you can use a List of Notification to implement a set of callback receivers

Answer 2

C++ to C# Callback Example

This works nicely to allow C++ to execute callbacks to C#.

Tested under:

• C#: Visual Studio 2015
• C++: Intel Parallel Studio 2017 SE
• C++: Should work nicely for Visual Studio 2015 C++ (can anyone verify this?).
• C++: Should work nicely for any other Windows C++ compiler that generates a standard .dll (can anyone verify this?).

In your SWIG .i file, include this file callback.i:

//////////////////////////////////////////////////////////////////////////
// cs_callback is used to marshall callbacks. It allows a C# function to
// be passed to C++ as a function pointer through P/Invoke, which has the
// ability to make unmanaged-to-managed thunks. It does NOT allow you to
// pass C++ function pointers to C#.
//
// Tested under:
// - C#: Visual Studio 2015
// - C++: Intel Parallel Studio 2017 SE
//
// Anyway, to use this macro you need to declare the function pointer type
// TYPE in the appropriate header file (including the calling convention),
// declare a delegate named after CSTYPE in your C# project, and use this
// macro in your .i file. Here is an example:
//
// C++: "callback.h":
//    #pragma once
//    typedef void(__stdcall *CppCallback)(int code, const char* message);
//    void call(CppCallback callback);
//
// C++: "callback.cpp":
//    #include "stdafx.h" // Only for precompiled headers.
//    #include "callback.h"
//    void call(CppCallback callback)
//    {
//        callback(1234, "Hello from C++");
//    }
//
// C#: Add this manually to C# code (it will not be auto-generated by SWIG):
//    public delegate void CSharpCallback(int code, string message);
//
// C#: Add this test method:
//    public class CallbackNUnit
//    {
//        public void Callback_Test()
//        {
//            MyModule.call((code, message) =>
//            {
//                // Prints "Hello from C++ 1234"
//                Console.WriteLine(code + " " + message);
//            });   
//        }        
//    }
//
// SWIG: In your .i file:
//   %module MyModule
//   %{
//     #include "callback.h"
//   %}
//   
//   %include <windows.i>
//   %include <stl.i>
//   
//   // Links typedef in C++ header file to manual delegate definition in C# file.
//   %include "callback.i" // The right spot for this file to be included!
//   %cs_callback(CppCallback, CSharpCallback)
//   #include "callback.h"
//
// As an alternative to specifying __stdcall on the C++ side, in the .NET
// Framework (but not the Compact Framework) you can use the following
// attribute on the C# delegate in order to get compatibility with the
// default calling convention of Visual C++ function pointers:
// [UnmanagedFunctionPointerAttribute(CallingConvention.Cdecl)]
//
// Remember to invoke %cs_callback BEFORE any code involving Callback. 
//
// References: 
// - http://swig.10945.n7.nabble.com/C-Callback-Function-Implementation-td10853.html
// - http://stackoverflow.com/questions/23131583/proxying-c-c-class-wrappers-using-swig             
//
// Typemap for callbacks:
%define %cs_callback(TYPE, CSTYPE)
    %typemap(ctype) TYPE, TYPE& "void *"
    %typemap(in) TYPE  %{ $1 = ($1_type)$input; %}
    %typemap(in) TYPE& %{ $1 = ($1_type)&$input; %}
    %typemap(imtype, out="IntPtr") TYPE, TYPE& "CSTYPE"
    %typemap(cstype, out="IntPtr") TYPE, TYPE& "CSTYPE"
    %typemap(csin) TYPE, TYPE& "$csinput"
%enddef
  

Answer 3

You can do this if you have a chance to pass some data around with the callback, but you'll need to write some JNI glue. I put together a complete example of how you might map C style callbacks onto a Java interface.

The first thing you need to do is decide on an interface that's appropriate on the Java side. I assumed in C we had callbacks like:

typedef void (*callback_t)(int arg, void *userdata);

I decided to represent that in Java as:

public interface Callback {
  public void handle(int value);
}

(The loss of the void *userdata on the Java side isn't a real problem since we can store state in the Object that implements Callback trivially).

I then wrote the following header file (it shouldn't really be just a header, but it keeps things simple) to exercise the wrapping:

typedef void (*callback_t)(int arg, void *data);

static void *data = NULL;
static callback_t active = NULL;

static void set(callback_t cb, void *userdata) {
  active = cb;
  data = userdata;
}

static void dispatch(int val) {
  active(val, data);
}

I was able to successfully wrap this C with the following interface:

%module test

%{
#include <assert.h>
#include "test.h"

// 1:
struct callback_data {
  JNIEnv *env;
  jobject obj;
};

// 2:
void java_callback(int arg, void *ptr) {
  struct callback_data *data = ptr;
  const jclass callbackInterfaceClass = (*data->env)->FindClass(data->env, "Callback");
  assert(callbackInterfaceClass);
  const jmethodID meth = (*data->env)->GetMethodID(data->env, callbackInterfaceClass, "handle", "(I)V");
  assert(meth);
  (*data->env)->CallVoidMethod(data->env, data->obj, meth, (jint)arg);
}
%}

// 3:
%typemap(jstype) callback_t cb "Callback";
%typemap(jtype) callback_t cb "Callback";
%typemap(jni) callback_t cb "jobject";
%typemap(javain) callback_t cb "$javainput";
// 4:
%typemap(in,numinputs=1) (callback_t cb, void *userdata) {
  struct callback_data *data = malloc(sizeof *data);
  data->env = jenv;
  data->obj = JCALL1(NewGlobalRef, jenv, $input);
  JCALL1(DeleteLocalRef, jenv, $input);
  $1 = java_callback;
  $2 = data;
}

%include "test.h"

The interface has quite a few parts to it:

1. A struct to store the information needed to make a call to the Java interface.
2. An implementation of the callback_t. It accepts as user data the struct we just defined and then dispatches a call to the Java interface using some standard JNI.
3. Some typemaps that cause the Callback objects to be passed straight to the C implementation as a real jobject.
4. A typemap that hides the void* on the Java side and sets up a callback data and fills in the corresponding arguments for the real function to use the function we just wrote for dispatching calls back to Java. It takes a global reference to the Java object to prevent it from being garbage collected subsequently.

I wrote a little Java class to test it with:

public class run implements Callback {
  public void handle(int val) {
    System.out.println("Java callback - " + val);
  }

  public static void main(String argv[]) {
    run r = new run();

    System.loadLibrary("test");
    test.set(r);
    test.dispatch(666);    
  }
}

which worked as you'd hope.

Some points to note:

1. If you call set multiple times it will leak the global reference. You either need to supply a way for the callback to be unset, prevent setting multiple times, or use weak references instead.
2. If you have multiple threads around you will need to be smarter with the JNIEnv than I've been here.
3. If you wanted to mix Java and C implementations of callbacks then you'll need to expand on this solution quite a bit. You can expose C functions to be used as callbacks with %constant but these typemaps will prevent your wrapped functions from accepting such inputs. Probably you would want to supply overloads to work around that.

There's some more good advice in this question.

I believe that a solution for C# would be somewhat similar, with different typemap names and a differing implementation of the callback function you write in C.