Question 1

What is an isolate and how does it differ from a thread?

Accepted Answer

Definition: an isolate is an independent unit of execution with its own memory, its own event loop and its own garbage collector. Dart's parallelism is built on it. The key difference from a thread in one sentence: threads share memory, isolates do not. Then list the consequences — that is where the value of the answer lies: With no shared variables there are no race conditions, mutexes, locks or synchronized. For a candidate coming from Java or C++ this is the biggest conceptual shift, and it is exactly what the interviewer wants to hear. Communication is message passing only: SendPort/ReceivePort. Sent objects are deep-copied — the price of that safety: for large data the serialisation cost is a real problem. Because each isolate has its own heap, GC pauses are independent too — one isolate's collection does not stop another. Finish with a nuance: static and global variables are not shared either — each isolate gets its own copy. That is a genuine source of surprise when working with singletons and caches, and very few candidates mention it.

Question 2

When do you need an isolate, and when is async/await enough?

Accepted Answer

Open with one sentence and then unpack it: async fixes waiting, an isolate fixes computing. async is enough when the operation is waiting: a network request, a file read, a database query, a timer. No thread is held; the OS does the work while the event loop stays free for other tasks. Moving a network request into an isolate buys nothing and only adds spawn and copy overhead — the single most common mistake here. An isolate is needed when the operation occupies the CPU: parsing or encoding large JSON, image processing and resizing, cryptography and hashing, sorting a large list, CSV/PDF generation, ML inference. await does nothing for these, because the computation still runs on the same thread. Give the boundary as a number, which makes the answer concrete: at 60 fps Flutter has about 16 ms per frame. Synchronous work exceeding that drops a frame. So pure CPU work longer than ~16 ms is an isolate candidate. Finish with an honest caveat: isolates are not free — a few milliseconds and roughly 1-2 MB to spawn, plus copying arguments and results. For small work an isolate makes performance worse. So I do not decide without measuring: I look at the DevTools timeline for the function that exceeds the frame budget, and then decide.

Question 3

How do you choose between Isolate.run, compute() and Isolate.spawn?

Accepted Answer

Separate them by usage scenario. Isolate.run(fn) (Dart 2.19+) — the modern, correct choice for one-shot work: it spawns, runs fn, returns the result and shuts the isolate down. Its advantages: it accepts closures (no top-level-function requirement), it rethrows errors on the main isolate so ordinary try/catch works, and it has no Flutter dependency, so it works in pure Dart packages too. compute(fn, arg) — Flutter's older helper for the same idea, now essentially built on Isolate.run. It survives in older code; in new code I write Isolate.run because it is not tied to Flutter and the API is more convenient. Isolate.spawn(entryPoint, message) — the low-level API. I pick it in two cases: (1) the isolate must be long-lived and I will keep sending it tasks — a worker pool, continuous video/audio decoding, background sync; (2) I need two-way communication (progress reporting, a cancellation signal). Here the ReceivePort/SendPort handshake, cancellation and kill() are all mine to write. Sum the choice up in a short rule: one-shot work → Isolate.run; repeated work or ongoing communication → a long-lived worker via Isolate.spawn; legacy Flutter code → compute. One extra argument: calling Isolate.run for each of many small tasks pays the spawn cost every time — that is exactly where a worker pool gives a measurable win.

Question 4

What can and cannot be sent to an isolate, and where does that restriction come from?

Accepted Answer

Start from the reason, not the list — that is what makes the answer memorable: isolates share no memory, so everything sent must be copyable. Anything that cannot be copied cannot be sent. That one principle explains the whole list. Sendable: null, num, bool, String, TypedData, List/Map/Set of those, SendPort, Capability. Since Dart 2.15, most ordinary objects too (deep-copied), and even top-level/static functions and closures — which is what lets Isolate.run accept a closure. Not sendable, with the reason for each: A ReceivePort itself — it is a specific isolate's mailbox, and copying it would be meaningless. That is why the handshake sends a sendPort instead. Open Socket and File handles and dart:ffi pointers — these are references to OS resources; a copy would point at nothing. In Flutter, anything tied to the UI: a BuildContext, an image handle, a platform channel — they belong to the UI isolate. Attempting any of them gives an ArgumentError. State the practical consequences too, which signal experience: (1) send raw data to the isolate (a JSON string or a byte array) rather than an object graph — copying gets cheaper; (2) for large byte blocks use TransferableTypedData, which transfers ownership instead of copying and makes a serious difference on expensive payloads; (3) if you open a new resource inside the isolate (a file, a socket), close it there — you cannot send it back.

Question 5

What does an isolate really cost, and how do you decide whether to use one?

Accepted Answer

This question exists precisely to separate candidates who think an isolate is always good. Break the cost into three parts: 1. Spawning. A new heap, a new event loop, runtime setup — typically a few milliseconds and roughly 1-2 MB on a mobile device. Isolate.run pays this on every call. 2. Copying. Arguments and results are serialised. For a large object graph that can cost more than the computation itself. The worst case is a small computation over a huge payload. 3. Complexity. With Isolate.spawn, the handshake, cancellation, error propagation and kill() are all yours to write — more code and more places to get it wrong. Describe the decision process as steps: First I measure: I look at the DevTools timeline for the function exceeding the 16 ms frame budget. I do not decide from guesswork. If the work is waiting (network, I/O) — no isolate is needed at all. If it is CPU-bound but short (<10 ms) — the isolate costs more than it saves; I either leave it or improve the algorithm. If it is CPU-bound and long — an isolate. Isolate.run for one-shot work, a long-lived worker if it repeats. If the data is large — I send it raw (bytes or a string), consider TransferableTypedData, and try to keep the result small too. The strongest ending is to name the alternative: often the best optimisation is not moving the work elsewhere but not doing it at all. Asking the server for a smaller JSON, caching the result, parsing lazily or paginating usually beats an isolate — and adds no complexity.

Question	`async`/`await`	Isolate
Which problem does it solve?	Waiting — I/O, network, files, timers	Computing — CPU-bound work
How many threads?	One — concurrency by interleaving	A separate one — true parallelism
Memory	Shared — every object is reachable	Separate — message passing only
Race-condition risk	Yes — state can change during an async gap	No — there is no shared state
Cost	Practically zero	Spawn time (~ms) + copying arguments and results + memory
Cancellation	None (a Future cannot be cancelled)	`isolate.kill()` — genuine cancellation

Isolates and concurrency

📚 Sources and documentation