Coroutines¶

Coroutines are computer program components that can be suspended and resumed — generalizing subroutines — for cooperative multitasking.

Version: v1 · 2026-09-28 · History
Domain-specific #: 8735
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomains: Programming Languages, Control Flow → Computer Science & Software Engineering

Core Idea¶

Coroutines is treated here as the recurring computing and information systems identity summarized by this source-grounded definition: Coroutines are computer program components that can be suspended and resumed — generalizing subroutines — for cooperative multitasking.

Coroutines are computer program components that can be suspended and resumed — generalizing subroutines — for cooperative multitasking. Coroutines are well-suited for implementing familiar program components such as cooperative tasks, exceptions, event loops, iterators, infinite lists and pipes. They have been described as "functions whose execution you can pause".

Melvin Conway coined the term coroutine in 1958 when he applied it to the construction of an assembly program. The first published explanation of the coroutine appeared later, in 1963. Importantly, whether a coroutine is symmetric or asymmetric has no bearing on how expressive it can be, though full coroutines are more expressive than non-full coroutines.

For Coroutines, the abstraction is narrower than the article's general subject matter: a positive case must preserve Coroutines are computer program components that can be suspended and resumed — generalizing subroutines — for cooperative multitasking. Retaining only the name, a familiar example, or a downstream effect is insufficient. The specialist roles and tests remain anchored in computing and information systems, which is why this identity is domain-specific rather than prime.

How would you explain it like I'm…

Pause-and-Continue Helpers

Imagine reading a bedtime story, stopping at a bookmark, playing a game, and later opening the story right where you left off. Coroutines are pieces of a computer program that can pause like that and pick up again later, taking turns with other pieces.

Taking-Turns Program Parts

A computer program is made of pieces that do jobs. Usually, a piece starts, runs until it's finished, and then hands control back. A coroutine is a special piece that can pause in the middle, let another piece run, and later continue exactly where it stopped, remembering everything. The pieces politely take turns instead of being interrupted, which is called cooperative multitasking. This is handy for things like producing a long list one item at a time or passing data down a line of steps.

Suspendable Resumable Routines

Coroutines are program components that can be suspended and later resumed, keeping their state in between. They generalize subroutines (ordinary functions): a subroutine runs from start to finish each time it's called, while a coroutine can stop partway, hand control elsewhere, and continue from the same point — 'functions whose execution you can pause.' Because each coroutine chooses when to give up control, they support cooperative multitasking, as opposed to a system that forcibly switches between tasks. They're a natural way to build iterators, event loops, pipelines, infinite lists, and cooperative tasks. The term was coined by Melvin Conway in 1958.

Coroutines are program components that can be suspended and resumed, generalizing subroutines, and are used for cooperative multitasking. Where a subroutine has a single entry and runs to completion before returning, a coroutine can yield control mid-execution and later resume from that point with its local state preserved. Control transfer is voluntary, which distinguishes cooperative multitasking from preemptive scheduling. Coroutines are well suited to implementing cooperative tasks, exceptions, event loops, iterators, infinite lists, and pipes. Melvin Conway coined the term in 1958 for the construction of an assembly program, and the first published explanation appeared in 1963. Whether coroutines are symmetric or asymmetric does not affect their expressive power, but full coroutines are more expressive than non-full ones.

Structural Signature¶

Sig role-phrases:

Defining carrier — Further, each mutually recursive call of a subroutine requires a new stack frame (unless tail call elimination is implemented), while passing control between coroutines uses the existing contexts and can be implemented simply by a jump.
Constitutive relation — Go has a built-in concept of "goroutines", a type of green thread which are lightweight, independent processes managed by the Go runtime.
Operating condition — whether coroutines are provided in the language as first-class objects, which can be freely manipulated by the programmer, or as constrained constructs.
Recognition evidence — By contrast, coroutines can exit by calling other coroutines, which may later return to the point where they were invoked in the original coroutine; from the coroutine's point of view, it is not exiting but calling another coroutine.
Admissible variation — Although this example is often used as an introduction to multithreading, two threads are not needed for this: the yield statement can be implemented by a jump directly from one routine into the other.
Characteristic consequence — Coroutines provide concurrency, because they allow tasks to be performed out of order or in a changeable order, without changing the overall outcome, but they do not provide parallelism, because they do not execute multiple tasks simultaneously.
Failure boundary — However, it is still possible to implement coroutines on top of a generator facility, with the aid of a top-level dispatcher routine (a trampoline, essentially) that passes control explicitly to child generators identified by tokens passed back from the generators.

What It Is Not¶

Not the whole field of computing and information systems. The node requires the specific identity stated by Coroutines are computer program components that can be suspended and resumed — generalizing subroutines — for cooperative multitasking.
Not an over-broad reading. However, goroutines are not coroutines (for instance, local data does not persist between successive calls).
Not an over-broad reading. However, coroutines are cooperatively multitasked, whereas threads are typically preemptively multitasked.
Not an over-broad reading. Since coroutines yield rather than return, and then resume execution rather than restarting from the beginning, they are able to hold state, both variables (as in a closure) and execution point, and yields are not limited to being in tail position; mutually recursive subroutines must either use shared variables or pass state as parameters.
Not automatically Calculus of Communicating Systems. Retrieval proximity does not establish equivalence; the two identities must be compared by carrier, operation, and failure boundary.

Scope of Application¶

Coroutines applies literally inside computing and information systems wherever the source-defined carrier and relation can be established. Its documented habitats include:

Assembly languages. Once a second call stack has been obtained with one of the methods listed above, the setjmp and longjmp functions in the standard C library can then be used to implement the switches between coroutines.
Assembly languages. This is the approach recommended by Tom Duff in a discussion on its relative merits vs. the method used by Protothreads.
Java. There are four general methods used, but two break bytecode portability among standards-compliant JVMs.
Java. These use JNI methods implemented in the OS or C libraries to provide the functionality to the JVM.
Assembly languages. This can be significantly faster, as setjmp and longjmp must conservatively store all registers which may be in use according to the ABI, whereas the clobber method allows the compiler to store (by spilling to the stack) only what it knows is actually in use.
Definition and types. whether a coroutine is able to suspend its execution from within nested function calls.

Outside computing and information systems, the name should be retained only when these same operational conditions survive; otherwise the comparison belongs to the broader parent Pattern or should be marked as analogy.

Clarity¶

A clear use of Coroutines names the carrier, the operative relation, and the conditions under which the source treats the identity as present. The minimal definition is Coroutines are computer program components that can be suspended and resumed — generalizing subroutines — for cooperative multitasking. The strongest recognition evidence in the frozen account is: By contrast, coroutines can exit by calling other coroutines, which may later return to the point where they were invoked in the original coroutine; from the coroutine's point of view, it is not exiting but calling another coroutine. A report should distinguish that evidence from a proxy, consequence, or common implementation. It should also state the qualification However, goroutines are not coroutines (for instance, local data does not persist between successive calls). so that a reader can reproduce the classification rather than infer it from topical resemblance.

Manages Complexity¶

Coroutines compresses multiple computing and information systems details into a stable diagnostic relation. The source shows both the central mechanism—go has a built-in concept of "goroutines", a type of green thread which are lightweight, independent processes managed by the Go runtime.—and the practical consequence—coroutines provide concurrency, because they allow tasks to be performed out of order or in a changeable order, without changing the overall outcome, but they do not provide parallelism, because they do not execute multiple tasks simultaneously. This compression makes cases comparable while leaving parameters, conventions, exceptions, and evidential quality explicit. It is lossy by design: local history and implementation details may be omitted only when they do not alter the defining relation.

Abstract Reasoning¶

Type the carrier. Identify the computing and information systems entities to which the claim applies.
State the relation. Use the source-grounded identity: Coroutines are computer program components that can be suspended and resumed — generalizing subroutines — for cooperative multitasking.
Check operation and conditions. whether coroutines are provided in the language as first-class objects, which can be freely manipulated by the programmer, or as constrained constructs.
Demand recognition evidence. By contrast, coroutines can exit by calling other coroutines, which may later return to the point where they were invoked in the original coroutine; from the coroutine's point of view, it is not exiting but calling another coroutine.
Test variation. Change an implementation or setting while preserving although this example is often used as an introduction to multithreading, two threads are not needed for this: the yield statement can be implemented by a jump directly from one routine into the other.
Run the collapse test. Remove the defining operation; if the label still seems equally apt, only a topic or correlate was retained.
Reduce cautiously. When the specialist conditions cannot be carried, route the residual comparison to Pattern.

Knowledge Transfer¶

Within the home domain. Knowledge about Coroutines transfers literally when a new case preserves the same carrier type, relation, and recognition test. Once a second call stack has been obtained with one of the methods listed above, the setjmp and longjmp functions in the standard C library can then be used to implement the switches between coroutines. This is the approach recommended by Tom Duff in a discussion on its relative merits vs. the method used by Protothreads.

Beyond the home domain. No canonical parent is asserted for Coroutines. An outside case receives the specialist name only when the same typed roles and rejection conditions can be filled literally; otherwise the comparison remains an analogy pending later graph densification.

Examples¶

Canonical¶

A number of implementations of coroutines for languages with generator support but no native coroutines (e.g. This case is canonical because it supplies a concrete carrier and lets the defining relation be checked rather than merely named.

Mapped back: carrier → the entities in the documented case; operation → Coroutines are computer program components that can be suspended and resumed — generalizing subroutines — for cooperative multitasking; recognition evidence → By contrast, coroutines can exit by calling other coroutines, which may later return to the point where they were invoked in the original coroutine; from the coroutine's point of view, it is not exiting but calling another coroutine

Applied / In Practice¶

Using coroutines for state machines or concurrency is similar to using mutual recursion with tail calls, as in both cases the control changes to a different one of a set of routines. The applied case shows how the identity is used under a second setting or qualification while keeping the same operative relation.

Mapped back: changed setting → Mutual recursion; invariant → Coroutines are computer program components that can be suspended and resumed — generalizing subroutines — for cooperative multitasking; boundary → the case exits the class when however, goroutines are not coroutines (for instance, local data does not persist between successive calls)

Structural Tensions¶

T1 — Stable identity versus admissible variation. However, goroutines are not coroutines (for instance, local data does not persist between successive calls). The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Which changes preserve the defining relation, and which replace it?

T2 — Recognition versus proxy. However, coroutines are cooperatively multitasked, whereas threads are typically preemptively multitasked. The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Does the cited evidence establish the identity or only a correlated sign?

T3 — Definition versus implementation. Since coroutines yield rather than return, and then resume execution rather than restarting from the beginning, they are able to hold state, both variables (as in a closure) and execution point, and yields are not limited to being in tail position; mutually recursive subroutines must either use shared variables or pass state as parameters. The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Is the observed implementation constitutive, optional, or merely common?

T4 — Scope versus overextension. When subroutines are invoked, execution begins at the start, and once a subroutine exits, it is finished; an instance of a subroutine only returns once, and does not hold state between invocations. The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Can every claimed application fill the same typed roles without metaphor?

T5 — Transfer versus domain accent. Further, each mutually recursive call of a subroutine requires a new stack frame (unless tail call elimination is implemented), while passing control between coroutines uses the existing contexts and can be implemented simply by a jump. The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Does the receiving case instantiate Coroutines literally, co-instantiate Pattern, or only resemble it?

T6 — Autonomy versus reduction. Go has a built-in concept of "goroutines", a type of green thread which are lightweight, independent processes managed by the Go runtime. The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: What does Coroutines distinguish that the broader parent Pattern leaves together?

Structural–Framed Character¶

Coroutines is mixed or framed-leaning. Its structural side is the repeatable organization summarized by Coroutines are computer program components that can be suspended and resumed — generalizing subroutines — for cooperative multitasking. Its framed side is the computing and information systems vocabulary that fixes the carrier, evidence, exceptions, and admissible transformations.

Evaluative weight: the identity can be stated descriptively even when applications carry practical stakes. Human-practice dependence: the source-grounded carrier determines whether the relation exists independently or is constituted by a practice. Institutional origin: disciplinary conventions stabilize the name and test. Vocabulary portability: whether coroutines are provided in the language as first-class objects, which can be freely manipulated by the programmer, or as constrained constructs. Import versus recognition: literal transfer requires the same mechanism; shape alone is analogy.

Its portable skeleton is Pattern. Its character: a recurring specialist identity whose thin organization can be abstracted, while its operational meaning remains domain-bound.

Structural Core vs. Domain Accent¶

What is skeletal. Coroutines are computer program components that can be suspended and resumed — generalizing subroutines — for cooperative multitasking. The stable skeleton is the typed relation expressed in that definition and the entry's recognition and collapse tests. The source identifies these operative conditions: Further, each mutually recursive call of a subroutine requires a new stack frame (unless tail call elimination is implemented), while passing control between coroutines uses the existing contexts and can be implemented simply by a jump. Go has a built-in concept of "goroutines", a type of green thread which are lightweight, independent processes managed by the Go runtime. It further constrains recognition and variation through: whether coroutines are provided in the language as first-class objects, which can be freely manipulated by the programmer, or as constrained constructs. By contrast, coroutines can exit by calling other coroutines, which may later return to the point where they were invoked in the original coroutine; from the coroutine's point of view, it is not exiting but calling another coroutine.

What is domain-bound. computing and information systems supplies the operative entities, technical vocabulary, warrants, and exceptions that make Coroutines literal. Its documented scope includes the condition that Once a second call stack has been obtained with one of the methods listed above, the setjmp and longjmp functions in the standard C library can then be used to implement the switches between coroutines. Another bounded application condition is that This is the approach recommended by Tom Duff in a discussion on its relative merits vs. the method used by Protothreads. These are not decorative examples; they determine which carrier and evidence can fill the abstraction's roles.

Why no parent is asserted. Removing those specialist details does not currently yield one live catalog node that is a necessary genus for every instance. The entry is therefore approved as unparented rather than attached by topical resemblance. Its collapse evidence remains specific—Although this example is often used as an introduction to multithreading, two threads are not needed for this: the yield statement can be implemented by a jump directly from one routine into the other.—and future graph densification may discover a defensible relation only if it preserves that boundary.

Approved unparented node. No current live node supplies a defensible necessary genus or structural prerequisite for Coroutines. The reviewed identity is: Coroutines are computer program components that can be suspended and resumed — generalizing subroutines — for cooperative multitasking. The accelerated suggestion was declined because topical or lexical similarity does not establish hierarchy; the node is admitted without a parent pending later graph densification.
Related reasoning operations. Evidence, representation, comparison, classification, transformation, or evaluation may participate in particular cases, but participation does not make any one of them a necessary parent of every instance.

Neighborhood in Abstraction Space¶

Coroutines sits in a sparse region of the domain-specific corpus (82^nd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Computation Models & Complexity Classes (37 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With¶

Pattern. The parent omits the specialist differentia. Tell: Can the case establish Coroutines are computer program components that can be suspended and resumed — generalizing subroutines — for cooperative multitasking?
Calculus of Communicating Systems. Milner's process calculus in which action prefix, choice, parallel composition, restriction, relabeling, and recursion generate labelled transition systems whose binary handshakes become internal actions and whose behaviors are compared by bisimulation. Tell: Which entry's carrier, operation, and failure condition are satisfied?
Instruction pipelining. A processor implementation that divides instruction execution into stages and overlaps different instructions across those stages to increase throughput without requiring each instruction to finish before the next begins. Tell: Which entry's carrier, operation, and failure condition are satisfied?
Dovetailing (computer science). A fair scheduling technique that interleaves steps of multiple potentially nonterminating computations so none can block all others forever. Tell: Which entry's carrier, operation, and failure condition are satisfied?
A measurement, proxy, or consequence. Those may provide evidence without being the identity. Tell: Would Coroutines remain present if the detector or downstream effect changed?
A metaphorical analogue. A similar shape outside computing and information systems lacks the specialist mechanism. Tell: Do the native roles transfer literally, or only the parent Pattern?

References¶

Frozen Wikipedia discovery revision: https://en.wikipedia.org/wiki/Coroutine (revision 1370323968).
Preserved source candidate: https://snarky.ca/how-the-heck-does-async-await-work-in-python-3-5/
Preserved source candidate: https://web.archive.org/web/20230110140918/https://snarky.ca/how-the-heck-does-async-await-work-in-python-3-5/
Preserved source candidate: https://books.google.com/books?id=yQ9LAQAAIAAJ
Preserved source candidate: https://docs.python.org/reference/index.html
Preserved source candidate: https://web.archive.org/web/20121024054933/https://docs.python.org/reference/index.html
Preserved source candidate: https://docs.python.org/reference/expressions.html#yieldexpr
Preserved source candidate: https://web.archive.org/web/20121026064102/https://docs.python.org/reference/expressions.html#yieldexpr
Preserved source candidate: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Coroutine

The frozen Wikipedia revision is discovery provenance. The retained source set was reviewed for identity, formal or operational relation, and scope. The encyclopedia's structural synthesis is bounded to those claims; a thin authority surface is recorded as a nonblocking source-strengthening repair rather than concealed.