This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: RFC: variadic closures in x86/x86_64
- From: Andrew Haley <aph at redhat dot com>
- To: "Hogan, D. (GE Power & Water)" <D dot Hogan at ge dot com>
- Cc: Alan Modra <amodra at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>, "libffi-discuss at sourceware dot org" <libffi-discuss at sourceware dot org>
- Date: Wed, 04 Dec 2013 12:21:18 +0000
- Subject: Re: RFC: variadic closures in x86/x86_64
- Authentication-results: sourceware.org; auth=none
- References: <F023C084BCC16446BDA5B664305741E8090811 at ALPMBAPA05 dot e2k dot ad dot ge dot com> <52931854 dot 6080007 at redhat dot com> <20131125093715 dot GU892 at tucnak dot redhat dot com> <5293221D dot 4010505 at redhat dot com> <20131126142723 dot GD9211 at bubble dot grove dot modra dot org> <F023C084BCC16446BDA5B664305741E8091C7D at ALPMBAPA05 dot e2k dot ad dot ge dot com>
On 12/04/2013 08:02 AM, Hogan, D. (GE Power & Water) wrote:
> On Wed, Nov 27, 2013 at 00:57:23PM +1030, Alan Modra wrote:
>> The claim to fame looks to be the ability to call variadic functions
>> without describing the arguments via ffi_prep_cif_var at the point of
>> call. Instead you do so in the function consuming the args. I'm not
>> sure what that gains you..
>
> This is specifically for variadic callbacks. If it wasn't a callback,
> I could use ffi_prep_cif_var.
>
> To give a little background, FMI is a standard for (among other things)
> model exchange so you can use a dynamic system model in various
> modeling or simulation environments. The model is exposed as a C shared
> library. The shared library executes callbacks (some variadic) provided
> by a FMU driver.
Please, I'm finding this extremely difficult to understand. Where is
the variadic function? You say that a C shared library "executes" a
callback, but what does that mean?
At the point of the call, the caller knows for certain what arguments
are passed, and the type of these arguments.
> JFMI allows you to drive a FMU from Java. The Java FMU driver provides
> a Java implementation for the C callbacks.
Right, so a C program thinks it's calling C, but in fact it's calling
Java, and a libffi closure provides the glue.
> The nonvariadic callbacks
Ah! OK, so the function that is called as a C function is a libffi
closure, and it is called in a variadic form.
> were already supported by JFMI through libffi and JNA. In order to
> handle variadic callbacks, libffi and JNA need to be modified so you
> can access the variadic arguments inside of a callback. This patch
> adds the libffi support.
>
> I cannot construct a ffi_prep_cif_var because the model's C shared
> library is the one running a variadic callback in the driver.
Again, I don't know what it means to "run a variadic callback." Does
this mean that the shared library contains this callback function, or
that it calls it?
> I don't
> know how many arguments or what types it will provide in the calls. I
> have to rely on printf style formatting flags in order to know what to
> access from inside of the callback.
OK, so I'm guessing that the C model's shared library calls the variadic
function.
Why do you not define a variadic C function which does this:
void f1(int n, ...) {
va_list ap;
jintArray argsArray = (*env_p)->NewIntArray(n);
jint *args = (*env_p)->GetIntArrayElements(argsArray, NULL);
int argno = 0;
va_start(ap, n);
while (argno < n) {
args[argno++] = va_arg(ap, int);
}
va_end(ap);
(*env_p)->ReleaseIntArrayElements(argsArray, args, 0);
(*env_p)->CallStaticVoidMethod(clsH, printargs, argsArray);
}
to call this variadic Java code:
public static void printargs(int... args) {
for (int i : args)
System.out.print(i + " ");
System.out.println();
}
There is no reason that JNA cannot use this mechanism, is there?
Andrew.