Examine the code in using_spawn.dart to create isolates with spawn, as shown in the following code:

import'dart:async';
import'dart:isolate';

main() {
  // 1- make a ReceivePort for the main isolate:
  varrecv = new ReceivePort();
  // 2- spawn a new isolate that runs the code from the echo      // function
  // and pass it a sendPort to send messages to the main isolate
  Future<Isolate> remote = Isolate.spawn(echo, recv.sendPort);
  // 3- when the isolate is spawned (then), take the first message
  remote.then((_) =>recv.first).then((sendPort) {
  // 4- send a message to the isolate:
  sendReceive(sendPort, "Do you hear me?").then((msg) {
  // 5- listen and print the answer from the isolate
  print("MAIN: received $msg");
  // 6- send signal to end isolate:
  returnsendReceive(sendPort, "END");
  }).catchError((e) => print('Error in spawning isolate $e'));
  });
  }
  
  // the spawned isolate:
  void echo(sender) {
  // 7- make a ReceivePort for the 2nd isolate:
  var port = new ReceivePort();
  // 8- send its sendPort to main isolate:
  sender.send(port.sendPort);
  // 9- listen to messages
  port.listen((msg) {
  var data = msg[0];
  print("ISOL: received $msg");
  SendPortreplyTo = msg[1];
  replyTo.send('Yes I hear you: $msg, echoed from spawned isolate'),
  // 10- received END signal, close the ReceivePort to save         // resources:
  if (data == "END") {
  print('ISOL: my receivePort will be closed'),
  port.close();
  }
  });
}

Future sendReceive(SendPort port, msg) {
  ReceivePortrecv = new ReceivePort();
  port.send([msg, recv.sendPort]);
  returnrecv.first;
}

This script produces the following output:

ISOL: received [Do you hear me?,SendPort]

MAIN: received Yes I hear you: [Do you hear me?,SendPort], echoed from spawned isolate

ISOL: received [END, SendPort]

ISOL: my receivePort will be closed

From the output, we see that the main isolate receives its message echoed back from the second isolate. Examine the code in using_spawnuri.dart to create isolates with spawnUri:

import'dart:async';
import'dart:isolate';

main() {
  varrecv = new ReceivePort();
  Future<Isolate> remote =
  Isolate.spawnUri(Uri.parse("echo.dart"),
  ["Do you hear me?"], recv.sendPort);
  remote.then((_) =>recv.first).then((msg) {
  print("MAIN: received $msg");
  });
}

The following is the code from echo.dart:

import'dart:isolate';

void main(List<String>args, SendPortreplyTo) {
  replyTo.send(args[0]);
}

The following is the output:

MAIN: received Do you hear me?

Isolates are defined in their own library called dart:isolate. They conform to the well-known actor-model: they are like separate little applications that only communicate with each other by passing asynchronous messages back and forth; in no way can they share variables in memory. The messages get received in the order in which you send them. Each isolate has its own heap, which means that all values in memory, including global variables, are available only to that isolate. Sending messages, which comes down to serializing objects across isolates, has to obey certain restrictions. The messages can contain only the following things:

When isolates are created via spawn, they are running in the same process, and then it is also possible to send objects that are copied (currently only in the Dart VM).

An isolate has one ReceivePort to receive messages (containing data) on; it can listen to messages. Calling the sendport getter on this port returns SendPort. All messages sent through SendPort are delivered to the ReceivePort they were created from. On SendPort, you use the send method to send messages; a ReceivePort uses the listen method to capture these messages.

For each ReceivePort port there can be many SendPort. A ReceivePort is meant to live for as long as there is communication, don't create a new one for every message. Because Dart does not have cross-isolate garbage collection, ReceivePort is not automatically garbage-collected when nobody sends messages to them anymore.

When working with isolates, a ReceivePort in the main or root isolate is obligatory.

Schematically, we could represent it as shown in the following diagram:

A new isolate is created in one of the following two ways:

Isolates start out by exchanging SendPort in order to be able to communicate. Both methods return a Future with isolate, or an error of type IsolateSpawnException, which must be caught. This can be done by chaining a catchError clause or using the optional onError argument of spawn. However, an error occurring in a spawned isolate cannot be caught by the main isolate, which is logical, because both are independent code sets being executed. You can see this for yourself by running isolates_errors.dart. Keep in mind the following restrictions when using spawn and spawnUri:

So, if you have a compute-intensive task to run inside your app, then to keep your app responsive, you should put the task into its own isolate or worker. If you have many such tasks, then how many isolates should you deploy? In general, when the tasks are compute-intensive, you should use as many isolates as you expect to have cores or processors available. Additional isolates that are purely computational are redundant. But if some of them also perform asynchronous calls (such as I/O for example), then they won't use much processor time. In that case, having more isolates than processors makes sense; it all depends on the architecture of your app. In extreme cases, you could use a separate isolate for each piece of functionality or to ensure that data isn't shared.

As demonstrated in the second example, spawnUri provides a way to dynamically (that is, in run-time) load and execute code (perhaps even an entire library). Don't confuse Futures and isolates; they are different and are also applied differently.

At this moment, isolates are not very lightweight in the sense of Erlang processes, where each process only consumes a small amount of memory (of the order of Kb). Evolving isolates towards that ideal is a longer-term goal of the Dart team. Also, exception handling and debugging within isolates are a bit rough or difficult; expect this to change. It is also not specified how isolates map to operating system entities such as threads or processes; this can depend on the environment and platform. Isolates haven't been extended yet to inter-VM communication.