[vm/ffi] Support asynchronous callbacks

[sjindel-google]

Update Sept 6, 2023: Asynchronous callbacks with void returns can now be done with NativeCallable.listener from Dart 3.1.

Update March 12, 2020: Asynchronous callbacks can be done through the native ports mechanism. See the samples in samples/ffi/async and corresponding c code. In the future we would like to add a more concise syntax that requires less boilerplate code.

An asynchronous callback can be invoked outside the parent isolate and schedules a microtask there.

[dcharkes]

Asynchronous callbacks can be invoked on an arbitrary thread.

Synchronous callbacks cannot be invoked on an arbitrary thread because it would break the Dart language semantics: only one thread executing Dart per isolate.

Note that we need a solution for managing isolate lifetime when registering an asynchronous callback to be called from any thread in C. If the isolate died, and the callback is called, we have undefined behavior. A possible solution suggested by @mkustermann is to provide call-once callbacks, and keep the isolate alive until they are all called exactly once. Or we could have a counter or an arbitrary condition that we can check.

[dcharkes]

For inspiration, Kotlin requires the C library to be aware of Kotlin when doing non-main-thread-callbacks:

If the callback doesn't run in the main thread, it is mandatory to init the Kotlin/Native runtime by calling kotlin.native.initRuntimeIfNeeded().

Source: https://github.com/JetBrains/kotlin-native/blob/master/INTEROP.md#callbacks

[sjindel-google]

It's not the thread which the callback is tied to, it's the isolate. So our callbacks may be invoked on any thread so long as that thread has called Dart_EnterIsolate.

[dcharkes]

It's not the thread which the callback is tied to, it's the isolate. So our callbacks may be invoked on any thread so long as that thread has called Dart_EnterIsolate.

I presume Dart_EnterIsolate also (could) prevent isolates from being shutdown or killed.

[sjindel-google]

Another solution to managing lifetime is that the asynchronous callbacks need to be explicitly de-registered, and the isolate lives until all callbacks are de-registered.

Another challenge is knowing which Isolate the callback should run on. In AOT we have only one trampoline per target method, and there may be indefinitely many isolates from the same source at runtime.

[derolf]

Does it mean that calling back into Dart works as long as Dart_EnterIsolate is called before invoking the callback? How does the native code know that?

[dcharkes]

We have not made a design for this feature yet, we'll explore the possibilities when creating a design.

[derolf]

Okay, we have a workaround for it:

• Native: Thread X wants to run callback
• Native: Thread X adds the callback to a global list of pending callbacks
• Native: Thread X send sigusr1 to the process
• Dart: Main Isolate watches sigusr1 (using ProcessSignal.watch) and gets woken up
• Dart: Main Isolate calls via FFI into a function that executes all pending callbacks

[dcharkes]

@derolf nice!

Would you like to provide a minimal sample and contribute it as a PR for others to learn from for the time being?

[derolf]

It didn’t work so far because Flutter itself is using SIGUSR1/2 for hot reloading.

However, I saw that a NativePort can be sent through FFI to the c-layer. Do you have any example how to send something to that nativePort from C?

[dcharkes]

@derolf, to my understanding the NativePort solution only works if you own the Dart embedder yourself.

cc @mkustermann

Linking flutter/flutter#46887.

[derolf]

Okay, I implemented a way that works reliable and clean.

The queue:

On the native side, you need a threadsafe queue that allows to:
-- Enqueue callbacks from some thread that you want to execute in the main isolate (enqueue)
-- Have a function exposed through ffi that blocks until there are callbacks in the queue (wait)
-- Have a function exposed through ffi that executes pending callbacks (execute)

The dance:

Now, you spawn a slave isolate that waits on the queue and then sends a message to the main isolate, and waits again, ... (forever loop)

The main isolate receives this message and calls into ffi to execute all pending callbacks.

If some thread wants to dispatch a callback, you enqueue it instead of calling it. This will wakeup the slave isolate and that will send the said message to main and main will deliver the callback.

That's it. Less than 100 LOC to do it all.

[mkustermann]

Have a function exposed through ffi that blocks until there are callbacks in the queue (wait)

That is slightly problematic in an event-loop based system. The synchronous blocking will prevent the isolate from processing any other messages (timers, socket i/o, ...).

We'll write an example on how this can be done already now with our dart_native_api.h and ports.