How is a coroutine different from a thread?

A strong answer

A strong candidate frames How is a coroutine different from a thread? around the exact memory layout, compiler semantics, and hardware execution model covered in Coroutine Lifecycles, Trampolines, and State Machines. Explain cooperative (not preemptive) scheduling, single stack vs shared, and explicit yield/resume versus kernel scheduling.

However, jumping between two infinite loops in a ping-pong benchmark is not a complete runtime. Real-world coroutines do not loop forever:

• They are dynamically spawned with custom parameters (worker(void *arg)).
• They yield when waiting for data (coro_yield()).
• They resume when work is ready (coro_resume()).
• They finish and return.

At the machine level, return emits an x86-64 ret instruction.

• ret pops the 8-byte value at (%rsp) and writes it into the Instruction Pointer (%rip).
• If you seeded the stack with only the entry function address, what sits on the stack after my_fiber_task finishes?
• Uninitialized stack memory or zeroes.

In a production interview, always connect the specification rule to its concrete runtime consequence: state what lives on the stack versus the heap or static storage segment, how the compiler or operating system validates alignments, lifetimes, and error codes, and what happens under adversarial or boundary inputs (such as zero-length buffers, integer overflow, concurrent mutation, or partial I/O). Backing your explanation with a small trace of register/memory state transitions immediately separates senior systems engineers from candidates who only memorized syntax.

What the interviewer is listening for

• Mastery of core invariant: Model explicit coroutine lifecycle states across CREATED, READY, RUNNING, SUSPENDED, and DEAD.
• Mastery of core invariant: Implement the trampoline pattern to intercept normal function returns and route back to the scheduler.
• Mastery of core invariant: Pass arbitrary user arguments and capture return codes safely across stack boundaries.
• Hardware and ABI awareness: Explaining how sizes, alignments, calling conventions, or kernel boundaries behave on real 64-bit targets rather than relying on implementation-defined assumptions.
• Defensive engineering: Naming the exact compiler flags (-Wall -Wextra -Werror), static analyzers, or runtime sanitizers (-fsanitize=address,undefined,thread) that verify correctness in CI.

Common mistakes

• Explaining only surface syntax without tracing the underlying memory addresses, ownership lifetime, or kernel/user-space state transitions.
• Assuming undefined behavior (such as signed overflow, uninitialized reads, strict-aliasing violations, or dangling pointers) will "just work" because it passed an unoptimized -O0 debug build.
• Ignoring return codes, partial reads/writes, alignment padding, or cleanup paths when an allocation or syscall fails midway through a function.