public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Haley <aph@redhat.com>
To: "Hogan, D. (GE Power & Water)" <D.Hogan@ge.com>
Cc: Alan Modra <amodra@gmail.com>, Jakub Jelinek <jakub@redhat.com>,
	       "libffi-discuss@sourceware.org"
	<libffi-discuss@sourceware.org>
Subject: Re: RFC: variadic closures in x86/x86_64
Date: Wed, 04 Dec 2013 12:21:00 -0000	[thread overview]
Message-ID: <529F1E3E.4010401@redhat.com> (raw)
In-Reply-To: <F023C084BCC16446BDA5B664305741E8091C7D@ALPMBAPA05.e2k.ad.ge.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.

  parent reply	other threads:[~2013-12-04 12:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-25  2:46 Hogan, D. (GE Power & Water)
2013-11-25  9:29 ` Andrew Haley
2013-11-25  9:37   ` Jakub Jelinek
2013-11-25 10:10     ` Andrew Haley
2013-11-26 14:27       ` Alan Modra
2013-12-04  8:03         ` Hogan, D. (GE Power & Water)
2013-12-04 11:05           ` Philip Ashmore
     [not found]             ` <F023C084BCC16446BDA5B664305741E8091E8B@ALPMBAPA05.e2k.ad.ge.com>
2013-12-05 13:03               ` Philip Ashmore
2013-12-04 12:21           ` Andrew Haley [this message]
2013-12-04 18:28             ` Hogan, D. (GE Power & Water)
2013-12-04 18:51               ` Andrew Haley
2013-12-05  0:47                 ` Hogan, D. (GE Power & Water)
2013-12-05  8:33                   ` Andrew Haley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=529F1E3E.4010401@redhat.com \
    --to=aph@redhat.com \
    --cc=D.Hogan@ge.com \
    --cc=amodra@gmail.com \
    --cc=jakub@redhat.com \
    --cc=libffi-discuss@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).