Provide a way to tell if an isolate has no more work to do

[nex3]

Isolate.addOnExitListener allows the owner of an isolate to listen for that isolate terminating. However, this notion of termination doesn't match the notion the VM uses to determine when a Dart application should exit. When running an application directly, the VM will exit once there are no more events scheduled on the event loop, no more timers running, no open ReceivePorts, and no external streams or futures that may fire. Being able to emulate that behavior is important when using isolates to run Dart scripts.

One possible solution would be to add something like Isolate.addOnDoneListener, which would fire using the same criteria as the VM. Another solution which is probably too radical would be to have isolates automatically terminate if they have no more work to do.

This is blocking dart-lang/pub#1204.

[kevmoo]

Could we have Future get done or similar? That feels like an easier API.

[sethladd]

cc @lrhn

[lrhn]

I'm not sure what is being asked for.
All isolates die when they have nothing keeping them alive, as you describe.
The onExitListener will receive an event when the isolate is dead. That's the only signal we have available - either it's dead or it's alive, there is no (visible) intermediate state where it's alive but has nothing to do.

[lrhn]

Re "Future get done" (request should probably be a separate issue):
The API is deliberately low-level since it requires receive ports and implicit receive ports are bad - they keep your isolate alive and you can't get to them and close them if you want to.

We can add a "Future get done" getter that is defined in terms of addOnExitListener (but remember that it will keep your isolate alive until the done future fires). We do have the "Steam get errors" getter so it's not unprecedented, but that only keeps the isolate alive while you are actually listening.

[nex3]

I'm not sure what is being asked for.
All isolates die when they have nothing keeping them alive, as you describe.
The onExitListener will receive an event when the isolate is dead.

This doesn't match my empirical testing. For example:

import 'dart:io';
import 'dart:isolate';

main() async {
  new File("child.dart").writeAsStringSync("void main() {}");

  var isolate = await Isolate.spawnUri(Uri.parse("child.dart"), [], null);
  var receivePort = new ReceivePort();
  isolate.addOnExitListener(receivePort.sendPort);
  await receivePort.first;
  print("Isolate is dead.");
}

This never terminates and never prints "Isolate is dead", despite the fact that the child isolate clearly has nothing keeping it alive.

[nex3]

Never mind, I figured it out! Because the child isolate starts running concurrently with the parent, it exits before addOnExitListener is called, meaning that the receive port never fires. The following code works as expected:

import 'dart:io';
import 'dart:isolate';

main() async {
  new File("test2.dart").writeAsStringSync("void main() {}");

  var isolate = await Isolate.spawnUri(Uri.parse("test2.dart"), [], null,
      paused: true);
  var receivePort = new ReceivePort();
  isolate.addOnExitListener(receivePort.sendPort);
  isolate.resume(isolate.pauseCapability);
  await receivePort.first;
  print("Isolate is dead.");
}

It would be nice to add something warning about this to the documentation for addOnExitListener and addErrorListener, though. Maybe "Since isolates run concurrently, it's possible for it to exit before the exit listener is established. To avoid this, start the isolate paused, add the listener, then resume it."

[kevmoo]

Perhaps this is a stronger argument for adding Future get done/complete/finished etc...

[nex3]

@kevmoo That wouldn't help in this case; the user would still need to know to start the isolate paused and then unpause it after registering the future.

[kevmoo]

@nex3 I'd argue that the future would be marked complete, regardless of if it was started paused or not.

It could represent the state of the isolate, without having to listen for an event.

[sethladd]

@nex3 your wish is my command: https://codereview.chromium.org/1181043003

[lrhn]

@kevmoo Isolates are isolated, so you don't have a way to know whether an isolate is dead without it telling you. We don't expose internals that allow you to check whether an isolate, or a receive port, is alive. That is what it would take to get information about an isolate that no longer exists.

All isolate communication is based on ports and ports keep the receiving isolate alive, so we don't want to set up connections that we don't need. That's why you need to explicitly ask for the done event - it keeps your own isolate alive to have a receive port waiting for the answer.

You can use the IsolateRunner from package:isolate - it always start up by asking for exit notification, and has an explicit close method to sever the connection if you don't want it any more.