Add Dart_NewClosure to dart_api.h

[gaaclarke]

Looking through the dart_api.h file there doesn't seem to be an easy way to communicate data asynchronously back to the embedder environment. If we had an easy way to wrap a c function into a Dart closure it would be helpful.

proposed signature:

typedef void (*Dart_ClosureCallback)(Dart_Handle, void*);
Dart_Handle Dart_NewClosure(Dart_ClosureCallback callback, void* user_data);

That will create a void Function(dynamic) closure. user_data is just passed along to the callback.

[mraleph]

If you really want to use Dart VM C API (see my note below though) you can do:

class MyClosure extends NativeFieldWrapper2 {
  // First native field would be Dart_ClosureCallback to call
  // Second native field would be user_data.
  void call(Object arg) native "MyClosure_call";
}

Then you can create MyClosure instance and tear-off its call method. That would give you necessary closure.

Note: I would however really-really discourage you from using API - FFI is the way forward. We have just kicked off a project to start shifting embedder bindings to FFI - starting with our own bindings see #43889. If we make enough progress on this in 2020 I can see us starting to deprecate parts of C API to shrink its surface. (/cc @mkustermann)

[mkustermann]

I suspect this request doesn't come from normal C <-> Dart interaction but rather from the wish to perform synchronous isolate spawning. I've filed #44088 and will add an API for that.

[gaaclarke]

I looked into using FFI to return the value once the future is resolved. I don't think Dart FFI supports finding symbols in its own executable. All the documentation shows loading auxiliary shared libraries and loading symbols from them. My use case is Dart, compiled with AOT, calling into a C function, both linked into the Flutter shared library.

I filed another issue related to this to document if we have a way for loading internal symbols #44126

[mraleph]

Right now using symbols from executable is only possible if they are not stripped. In which case you can go through DynamicLibrary.executable(). We are planning to add ways to extend lookup mechanisms beyond relying on dlsym - this is part of #43889.

[gaaclarke]

Thanks, I got this working with FFI. Creating the closure would have the benefit of attaching context data, the void*. With FFI I'll have to manually do that by: passing a pointer cast to an integer to Dart, having Dart pass it back to C, and casting it back to a pointer. Not a huge deal, but a quality of life improvement.

[maks]

@gaaclarke any chance you would have some notes or a pointer to Flutter SDK code where you did this with FFI?
I ask because I'm trying to figure out if it would be possible to adapt the approach that was done by this old code to make a Dart REPL by calling the Dart SDK embedder C API but now in 2022 using FFI, which it sounds is what you did in your case?

[gaaclarke]

@maks I don't think I ever used this in production code that I remember. I may have just been playing with dart:ffi since it first came out and was probably just playing with it to make it do what I wanted. I've always been a fan of making Dart a more friendly language to embed which means it needs great interop.

The REPL sounds cool, does the Dart debugger already have something similar? If not it would be useful there.

[maks]

No worries at all @gaaclarke, I was just hoping to have myself a bit of time if there was already some examples I could crib off.

And yes for sure, the VM Service does already handle expression eval very nicely and I am using it successfully in my repl package, but its statements where I got stuck and the initial approach of trying to handle them via hot-reload doesn't seem to work well. I just left a update on the Repl issue about why I was wanting to go down the Dart embedder API route to handle them.