Coroutines

A dispatcher decides which thread runs the coroutine. Main is the single UI thread — touch the interface only there. IO is a large elastic pool for blocking input/output such as files, sockets and database calls. Default is a CPU-bound pool sized to the number of cores.

launch returns a Job — fire-and-forget; if its body throws, the exception propagates to the parent immediately. async returns a Deferred<T> that carries a result, and it holds its exception until you call await(), which is where the failure is rethrown.

A CoroutineScope owns a Job that becomes the parent of every coroutine launched in it. That is structured concurrency: children are tied to a lifetime, the scope waits for them, and cancelling the scope cancels them all — so no coroutine outlives its owner or leaks.

A coroutine is not a thread: it is a suspendable computation the compiler turns into a state machine. Suspending frees the thread instead of blocking it, so a single thread runs many coroutines. Each one costs a small heap object rather than a megabyte-sized stack — hence millions.

Deferred<T> is a Job that also carries a result. You read it with the suspending await(), which frees the thread until the value is ready, whereas Future.get() blocks the caller. A Deferred is a child of its scope and is cancelled with it.

A CoroutineContext is an indexed set of elements — typically a Job, the dispatcher, a CoroutineName and a CoroutineExceptionHandler. A child inherits its parent's context but gets its own new Job, and anything passed to the builder overrides the inherited element with the same key.

synchronized blocks the thread and must not be held across a suspension point: the coroutine may resume on another thread and release a monitor it never took. Mutex.withLock suspends instead. It is not re-entrant — nesting it deadlocks.

runBlocking blocks the calling thread until its body and all its children finish — the bridge from blocking code into the coroutine world, which main and a test want. Inside coroutine code it wastes the thread suspension exists to free, and on Main it freezes the UI.

The compiler rewrites a suspend function into a state machine and adds a hidden Continuation parameter — continuation-passing style. Each suspension point is a state: suspending saves that state, returns from the function and frees the thread, and the continuation resumes it later, possibly on another thread.

withContext creates no new coroutine: it suspends the current one, runs the block on the given dispatcher and resumes with its result, so it is sequential and returns a value. launch starts a concurrent child and returns a Job, not a result.

GlobalScope is bound to no lifecycle, so its coroutines are never cancelled: a closed screen keeps loading, keeps its ViewModel reachable and may write into dead UI. Replace it with the owner's scope — viewModelScope, lifecycleScope, an injected app scope.

A submitted task is an orphan: nobody waits for it, cancelling the caller never stops it, and its failure sits unread in a Future. A scope makes each coroutine a child of its Job — the scope will not finish until every child does, cancellation propagates down to them, and a child's failure reaches the parent and cancels its siblings.

Awaiting on the spot serializes them: the first async is awaited before the second even starts, so the two second-long calls run back to back. Start both builders first, keep the Deferreds in variables, and await them afterwards.

count++ is a read-modify-write, so concurrent coroutines overwrite each other's updates. Guard it with mutex.withLock { count++ } — acquiring suspends rather than blocking a pool thread. An AtomicInteger is the cheaper lock-free alternative.

Default runs CPU-bound work, so it holds about one thread per core — more would only add context switching, not throughput. An IO thread sits blocked in a syscall instead of on the CPU, so IO grows elastically to far more threads (at least 64).

Bridge it with suspendCancellableCoroutine: give the SDK's callbacks a CancellableContinuation, resume it with the value or resumeWithException, and register invokeOnCancellation { handle.cancel() }. It may resume only once — ignore later callbacks.

viewModelScope dispatches to Dispatchers.Main, and launch alone does not move work off it. Both calls block rather than suspend, so they hold the UI thread. Wrap the query in withContext(Dispatchers.IO) and the parse in withContext(Dispatchers.Default).

load is called while already on dbDispatcher, and runBlocking blocks that one thread. The withContext(dbDispatcher) inside then queues work for the very thread that is parked, so neither side can progress — a deadlock. Make load a suspend fun, call db.load(id) directly and delete the runBlocking.

Write a suspend helper taking the call as a lambda: loop the attempts with a cancellable delay(backoff) between them, multiplying it and adding jitter. Rethrow a non-retryable error at once, and the last error when the attempts run out. Bound the call with withTimeout.

A coroutine is a compiler construct: suspend becomes a state machine with a Continuation, so suspending is a return rather than a park — at the price of colouring the whole call chain. A virtual thread is a runtime construct: existing blocking code unmounts from its carrier unchanged. Both cost a heap object, not an OS stack, but a native frame still pins a virtual thread.

Guard the API with a Semaphore(5) and wrap each call in semaphore.withPermit { … }. Acquiring suspends when all five are taken, so no thread is blocked, and withPermit releases in a finally, so a cancelled caller — waiting or in flight — gives its permit back.