An isolate is really just like a separate runtime, running in a separate thread. It's a language provided convenience (with some inter-isolate communication facilities but no shared memory). Think of it as running multiple node or python interpreter instances but with less hassle.

Yep, I was asking how Aqueduct is using them.

For a bit more detail:

The main isolate creates an Application instance that has N number of supervisors, one for each isolate. The isolates are launched and go thru their initialization steps, reporting back to their supervisor. The application completes its launch once all supervisors have reported back. It fails its launch if an isolate throws an error during initialization or does not hear back in a configurable timeout. Any inter-isolate messages sent during startup are queued until all isolates have completed startup.

Once the isolates are up and running, the main isolate doesn't do anything other than facilitate the inter-isolate message hub. Requests are delivered directly to the isolates running the web server.

When running automated tests, the default behavior is to run everything on the main isolate, since tests are run against a temporary database schema that only exists for the lifetime of the connection.

Yup! Each isolate has its own event loop... and I'll do a terrible job explaining that as its late in the day, so I included a reference link [1].

The memory consumption of an isolate depends on the size of the application code. Each isolate actually has its own copy of the application code that gets tuned by the VM over time. Even stuff like static variables are per-isolate. I just pulled up an OK sized Aqueduct project, and it looks like about 30-40MB per isolate. Most of that is probably Aqueduct itself. A worker isolate is likely an order of magnitude smaller.

1: https://webdev.dartlang.org/articles/performance/event-loop