Add synchronous API to spawn a new isolate within an isolate group

[mkustermann]

Right now any embedder can call Dart code which can spawn an isolate. If --enable-isolate-groups is turned on, the embedder will get then a Dart_InitializeParams.initialize_isolate callback to initialize the new isolates global state.

Embedder 
  |-- Invoke Dart
       |--call Isolate.spawn()      // <-- Returns `Future<Isolate>`
            |--> Dart VM
                 |--call `initialize_isolate`
                   |--> Embedder

This is cumbersome for various reasons:

• One of the calls appears to the caller as async, it returns a Future<Isolate> and it's hard for embedder to wait for the Dart_Isolate to be ready. It is possible, by letting the embedder callback that initializes the isolate talk e.g. via C++ Monitor back to the original embedder and give it the isolate.
• It is quite slow to go through Dart to achieve this
• It doesn't allow the embedder to easily distinguish normal helper isolates spawned via Isolate.spawn() (for which it wants the VM to run eventloop) from isolates where it likes custom control (e.g. multiple UI isolates, where it wants to install special message handler).

[gaaclarke]

I think it's impossible to wrap up Isolate.spawn in C++ with the current API because there is no way to transform a symbol string to a function for the first argument in Dart without the reflection library, which isn't always available. I also don't see a way to lookup a function from the Dart C API either.

If that is true, there is no working around this feature (which is a blocker for me =).

[mkustermann]

I think it's impossible to wrap up Isolate.spawn in C++ with the current API because there is no way to transform a symbol
string to a function for the first argument in Dart without the reflection library, which isn't always available. I also don't see a
way to lookup a function from the Dart C API either.

The notion of functions is really a VM-internal concept. The embedder as well as Dart code only deals with instances and closures (*1). So maybe what you would like to have is to obtain a closure for a top-level method?

The C-based API lets one call global functions / instance methods with Dart_Invoke(), lets one call closures via Dart_InvokeClosure() as well as lets one look up fields via Dart_Get(). Those primitives are enough to do almost anything (*2)

When one calls Isolate.spawn(<closure>, <msg>) one is really passing a closure as argument. Using the primitives above it's possible to get closures of top-level methods, e.g. by invoking a helper method that returns it. Afterwards the closure can be called via Dart_InvokeClosure().

(*1) If you have a Function fun in Dart it really means fun is a closure object.
(*2) One cannot use Dart_GetField() for tearing off static methods - it is only allowed for main methods inside the root library. This restriction could potentially be lifted.

[gaaclarke]

Thanks, that makes sense. I might be running into the limitations you are mentioning. Using Dart_GetField I can get "main" in my main.dart, it can't seem to get top-level functions in a different library though.

I think for my testing launching main is fine for my testing. I know you told me other things won't work but I'm not quick enough to understand it without being blocked by it. It's a bit confusing to me because it looks like Flutter should support launching different entry points with this API but only root+main works in my experience (https://github.com/gaaclarke/engine/blob/e0d515369fac81e34c2d48f39c6ca766096add54/runtime/dart_isolate.cc#L531)

[mkustermann]

It's a bit confusing to me because it looks like Flutter should support launching
different entry points with this API but only root+main works in my experience

One can easily work around that by making this:

@pramga('vm:entry-point')
Function get getEntryPointClosure => entryPoint;

void entryPoint(...) {...}

So instead of doing Dart_Get(<entryPoint>) + Dart_InvokeClosure(...) you would use Dart_Invoke(<getEntryPointClosure>) + Dart_InvokeClosure(...). If it's a big inconvenience we could lift the restriction that only main methods in root libraries can be torn off atm.