[vm/ffi] `NativeCallable.onTemporaryIsolate`

[dcharkes]

We might never build this, but let's have a tracking bug to point to.

https://api.dart.dev/stable/3.2.4/dart-ffi/NativeCallable/NativeCallable.listener.html enables async callbacks that return immediately upon calling and schedule the callback to be run on the Dart event loop of the right isolate. No return values can be returned.

https://api.dart.dev/stable/3.2.4/dart-ffi/NativeCallable/NativeCallable.isolateLocal.html enables sync callbacks with return values. The current thread must be the one entered in the target isolate.

If we would like to be able to run Dart code synchronously and get a return value, but we don't have access to a Dart isolate in the current thread, we could conceivably spawn a new temporary isolate.

This would incur some serious limitations:

• No access to other isolates / global state.
• No async / event loop. (Synchronous return.)

We're currently not exploring this. @liamappelbe

A way more general approach would be to have shared memory multithreading:

• Shared Memory Multithreading language#3531

[liamappelbe]

This has become more relevant recently, as a way of eliminating ffigen's generated ObjC code. Small ObjC trampolines are generated to fix dart-lang/native#835, but if we had temp isolate callbacks we could write these trampolines in Dart.

Are we happy with the NativeCallable.onTemporaryIsolate name? What about shortening it to NativeCallable.tempIsolate?

[dcharkes]

I'm happy with the longer name, it's more clear. cc @lrhn for naming!

Cross linking the other open issue for NativeCallable.blocking:

• [vm/ffi] Introduce a NativeCallable.blocking #54554

[lrhn]

"Avoid abbreviations" is a style rule, so "temp" isn't stylistic.

I'd drop "temporary" completely.
Maybe newIsolate, freshIsolate or spawnIsolate.

Is the isolates spawned first, out spawned synchronously when trying to fix the callback?
Can you do more than one callback during the same native call? If so, does it use the same isolate, or does it spawn a new isolate per callback?

How will you prevent the call from starting async computations? It's presumably an isolate in the same isolate group, so you can't control access to dart:async. Not that that would work since Future is exported by dart:core, and something like Finalizer also triggers async callbacks.

Does the isolate do Isolate.exit when the callback returns? (Then each callback will definitely need a separate isolate.)

[liamappelbe]

I'd drop "temporary" completely.
Maybe newIsolate, freshIsolate or spawnIsolate.

I wonder if those imply that it's an ordinary isolate with no limitations?

Is the isolates spawned first, out spawned synchronously when trying to fix the callback?
Can you do more than one callback during the same native call? If so, does it use the same isolate, or does it spawn a new isolate per callback?

There's existing temporary isolate infrastructure in place for NativeCallable.listener, and we were planning to reuse that. That means we'll be spawning a new isolate each time one of these callbacks is invoked. But we were also considering adding an optimisation to cache the temporary isolates (this optimisation would affect both NativeCallable.listener and NativeCallable.onTemporaryIsolate).

So I'd like to avoid making any promises about whether it's a fresh isolate or not, because we may want to change the implementation in future.

[dcharkes]

So I'd like to avoid making any promises about whether it's a fresh isolate or not, because we may want to change the implementation in future.

Even if it's not fresh, we might want to not leak any state. (e.g. reset all global fields?)

I can't find a pattern in our names yet:

• NativeCallable.listener: behaves like a listener - (One gotcha though is that it returns early before it has been run, leading to errors if arguments were on the stack. Which "listener" doesn't communicate.) (Maybe messageHandler would have signalled that more than listener, listeners are called synchronously usually)
• NativeCallable.isolateLocal: must be on the same thread as the thread that is the mutator of the isolate. The native-callable is isolate local. The native callable should be used isolate local?

So one name is behaves like or should be used as, and the other name is more about what it is. I guess sticking closer to what it is makes more sense. A native callable is run, so the kind of native callable is how it is run.

• NativeCallable.temporaryIsolate: the native callable is a temporary isolate or is run on temporary isolate? Communicates definitely no access to shared state. But does not communicate no async. Temporary isolate conceptually can have async.

Maybe the name doesn't really matter and we just pick something and add good documentation. 🤷

[liamappelbe]

NativeCallable.temporaryIsolate sgtm

[lrhn]

• NativeCallable.listener: could be async or asEvent.
• NativeCallable.isolateLocal: sync.

That exhausts the sync/async behaviors, so NativeCallable.temporaryIsolate is something else. Which it is, it does a synchronous callback to dart code by running it in parallel. It does that by using a temporary (possibly fresh) isolate.

About resetting globals, also needs to close all ports and clear the event queues, to make sure nothing survives. Then send onExit events. Basically what Isolate.exit does, just without merging the heap back in, so that heap can be reused. Then just resetting the globals may be cheaper than allocating a new isolate, but probably not by much, uf constants are already shared.

[mraleph]

I would strongly prefer we align semantics and naming with extensions we are exploring in context of shared memory multithreading proposal, so that we avoid introducing duplication and incurring additional migration / cognitive costs later.

Specifically, this means going for a variation of NativeCallable.shared which is described in the proposal.

Though I must admit that I don't like the name shared for callables because it is not descriptive enough - though I don't really see any good alternative. We need some word that describes callback which:

• is not bound to a specific isolate, but is bound to a specific isolate group.
• can't access isolate local state, but can access shared native memory.

There is no single word which clearly describes these capabilities and limitations.

[dcharkes]

Ah, this means it should be an error to access global fields completely in NativeCallable.temporaryIsolate. And not that all fields are reset before the next invocation.

@mraleph Could we theoretically support having unawaited futures in such code? E.g. would it be possible to have a message queue for the isolate group? (The native callable itself must be synchronous though due to the return value. So only unawaited futures.)

NativeCallable.notIsolateLocal? 🤣 It's synchronous like NativeCallable.isolateLocal, but is not local to an isolate. 😀

I like NativeCallable.shared, but not while it doesn't yet have access to any shared state. 🙈 But if we really only want to upgrade the semantics later, having users migrate to a new constructor name later is a churn.