Stackful Coroutines in WG21: A Case Study in Institutional Dynamics

Great Founder Theory in C++

Abstract

This paper analyzes the divergent trajectories of stackless coroutines (C++20) and stackful coroutines/fibers (still not standardized after 12+ years of proposals) through the lens of Great Founder Theory (GFT), Samo Burja’s framework for analyzing how institutions succeed or fail based on the presence of exceptional individuals and the dynamics of power. We examine why a well-understood, multiply-implemented, foundational primitive with clear use cases has languished in committee while a more complex, less complete facility was standardized. We identify the key individuals, corporations, and institutional dynamics that shaped this outcome, and examine structural concerns about how resource asymmetries and misaligned incentives may have influenced the process.

2. Timeline: Parallel Tracks, Divergent Outcomes

2.1 The Stackful Track (Kowalke/Goodspeed)

Oliver Kowalke, a German software engineer, began developing Boost.Context around 2009, providing low-level stackful context switching across platforms. This evolved into Boost.Coroutine (later Boost.Coroutine2) and Boost.Fiber, forming a complete ecosystem for stackful cooperative multitasking.

Nat Goodspeed, then at Linden Lab (creators of Second Life), collaborated with Kowalke on standardization efforts. Their joint work produced a sustained stream of proposals:

• N3708 (2013-09): A proposal to add coroutines to the C++ standard library

• N3985 (2014-05): A proposal to add coroutines to the C++ standard library (R1)

• N4024 (2014-05): Distinguishing coroutines and fibers

• N4397 (2015-04): A low-level API for stackful coroutines

• N4398 (2015-04): A unified syntax for stackless and stackful coroutines

• P0099R0 (2015-09): A low-level API for stackful context switching

• P0099R1 (2016-10): A low-level API for stackful context switching

• P0534R3 (2017-11): call/cc (call-with-current-continuation): A low-level API for stackful context switching

• P0876R0-R19 (2018-2024): fiber_context - fibers without scheduler

The proposal has now reached 19 revisions spanning over a decade. As of late 2024, P0876 remains tagged “needs-revision” and “lwg-waiting,” still not in the C++26 working draft despite being nominally targeted for that release.

2.2 The Stackless Track (Nishanov/Microsoft)

Gor Nishanov, a Principal Software Design Engineer on Microsoft’s C++ team, began working on stackless “resumable functions” around 2012. The trajectory was dramatically faster:

• N3858 (2014-01): Resumable Functions

• N3977 (2014-05): Resumable Functions (v2)

• N4134 (2014-10): Resumable Functions (revision)

• N4286 (2014-11): Resumable Functions (revision 4)

• N4402 (2015-04): Resumable Functions (revision 4)

• N4499 (2015-05): Draft wording for Coroutines

• P0057R0-R7 (2016-2018): Coroutines TS

November 2013: Microsoft ships experimental coroutine support in Visual Studio CTP—before any formal committee approval.

2017: Coroutines TS published.

February 2019: Coroutines merged into C++20 working draft at Kona with “very strong consensus” (~10:1 vote).

December 2020: C++20 published with coroutines.

The contrast is stark: stackless coroutines went from initial proposal to standard in approximately 6 years. Stackful coroutines have been in committee for 12 years and counting.

3. Technical Comparison

3.1 Stackful Coroutines (Fibers)

Stackful coroutines allocate a separate stack for each coroutine. This enables:

• Suspension from any call depth: A fiber can suspend from within arbitrarily nested function calls. The entire call stack is preserved.

• Transparency to called code: Functions called from a fiber need not be specially marked or aware they’re running on a fiber.

• Simpler mental model: A fiber behaves like a thread with cooperative (rather than preemptive) scheduling.

• Mature implementations: Boost.Context supports x86, x86_64, ARM, ARM64, MIPS, PowerPC, RISC-V, and S390x across Windows, Linux, macOS, iOS, Android, and others.

The primary cost is memory: each fiber requires stack space (typically 4KB-1MB depending on configuration).

3.2 Stackless Coroutines (C++20)

Stackless coroutines store only the coroutine frame (local variables and suspend point) on the heap. This enables:

• Minimal memory footprint: Each coroutine uses only the memory required for its frame.

• Potential billions of concurrent coroutines: The small footprint enables massive concurrency.

• Compiler optimization opportunities: The compiler can potentially elide heap allocation entirely (HALO - Heap Allocation eLision Optimization).

The costs include:

• Viral markup: Every function in the call chain that might suspend must be a coroutine. Suspension cannot occur from within a regular function called by a coroutine.

• Complexity: The promise_type/awaiter machinery is notoriously difficult to understand.

• No standard library support at ship: C++20 coroutines shipped without std::task, std::generator, or any usable types.

• Heap allocation overhead: Every coroutine entry (not just resumption) requires a heap allocation; every return (not just suspension) requires a deallocation. In nontrivial software with proper layers of abstraction, this leads to heap thrashing with significant runtime costs. Some proposals have gestured vaguely about memory pools for coroutines—but a memory pool for stack frames is called a “stack.” Microsoft has criticized Boost.Context’s segmented stack implementation for the possibility that repeated calls from function A to function B might cause heap thrashing. This critique is richly ironic: stackless coroutines exhibit this exact behavior on every call and return—toy examples excepted.

• HALO limitations: The much-touted Heap Allocation eLision Optimization is only possible when the coroutine can only be called from within the same translation unit. This optimization doesn’t scale from toy examples to enterprise software.

3.3 The “Distinct Use Cases” Finding

At the May 2015 Lenexa meeting, SG1 explicitly concluded that “stackless and stackful coroutines have distinct use cases and decided to pursue both technologies.” This finding was documented in P0099R0:

“The members of the committee concluded that stackless and stackful coroutines have distinct use cases and decided to pursue both technologies.”

This is crucial: the committee formally recognized these as complementary facilities, not competitors. Both were supposed to advance. Only one did.

4. Key Individuals and Their Roles

4.1 Gor Nishanov (Microsoft)

Nishanov served as the primary architect and advocate for stackless coroutines. His CppCon presentations (2014-2019) made a compelling case for the stackless approach, emphasizing its advantages for high-scale scenarios. In N4232, he argued:

“Design goals of scalability and seamless interaction with existing facilities without overhead... necessitates stackless coroutines. General purpose stackful coroutines that reserve default stack for every coroutine (1MB on Windows, 2MB on Linux) will exhaust all available virtual memory in 32-bit address space with only a few thousand coroutines.”

Nishanov’s focus on scalability was technically sound for certain use cases, even if it may have inadvertently framed stackful coroutines less favorably than warranted. Raymond Chen (also Microsoft) later published a blog post titled “Fibers aren’t useful for much any more,” citing Nishanov’s work. These perspectives, while legitimate technical viewpoints, may have shaped committee perception in ways that undervalued fibers’ distinct use cases.

4.2 Oliver Kowalke

Kowalke is the author and sole maintainer of Boost.Context, Boost.Coroutine2, and Boost.Fiber. As P0876R14 notes:

“Boost.Context is maintained by one individual to support the specific set of processors and operating systems to which he has access.”

This maintenance model—one person supporting a cross-platform assembly-language library—represents both remarkable dedication and institutional fragility. Kowalke has no corporate backing for his standardization work.

4.3 Nat Goodspeed

Goodspeed collaborated with Kowalke on the standardization effort, particularly on documentation, rationale, and committee presentation. His background at Linden Lab (where fibers were used extensively in the Second Life client application) provided real-world deployment experience.

4.4 The Resource Asymmetry

The resource difference between these efforts is significant:

• Nishanov: Full-time Microsoft employee with access to compiler team resources, corporate travel budget, and an implementation shipping in a production compiler since 2013

• Kowalke/Goodspeed: Volunteer effort without compiler team access, relying largely on personal resources for travel, with implementation in Boost only

Crucially, neither Linden Lab nor Kowalke’s employer had any institutional interest in advancing fiber technology. This stands in stark contrast to Microsoft’s major strategic investment in stackless coroutines. The asymmetry was not merely personal but institutional.

This raises questions about whether the committee process adequately accounts for such disparities.

5. Corporate Dynamics

5.1 Microsoft’s Investment and Perspective

Microsoft’s investment in stackless coroutines was substantial:

1. Compiler implementation: Years of engineering effort in MSVC

2. Azure integration: Coroutines positioned as key to efficient async I/O

3. Developer ecosystem: Visual Studio tooling, documentation, evangelism

4. Committee presence: Multiple Microsoft employees active in WG21

Such investments create institutional momentum. An employee representing their company at committee meetings naturally advocates for positions aligned with their employer’s strategic direction. Heavily-invested corporate positions tend to advance, while alternatives without similar backing may struggle regardless of technical merit.

5.2 The Absence of Stackful Champions

No major corporation championed stackful coroutines. Boost lacks the committee presence of Microsoft, Google, or NVIDIA. Kowalke and Goodspeed attended meetings as individuals, not corporate representatives.

In Great Founder Theory terms, the stackful proposal held only “borrowed power” (the prestige of Boost, the technical merit of the design) while lacking “owned power” (shipping implementations in major compilers, corporate backing, paid committee participation).

6. Structural Concerns and Process Questions

6.1 Observations from Committee Participants

Several committee participants have privately expressed concern that the process may have been influenced by factors beyond pure technical merit:

1. Asymmetric requirements: The stackful proposal appears to have faced more demanding requirements around edge cases (exception handling, thread-local storage, stack unwinding) than the stackless proposal faced at comparable stages.

2. Resource dynamics: Corporate-backed proposals can iterate faster, with dedicated engineers addressing feedback between meetings, while volunteer efforts face inherent constraints.

3. Framing effects: When influential voices characterize a technology as obsolete or inferior, it shapes how reviewers approach subsequent proposals.

4. The 2019 TS redirect: At Cologne 2019, after years of SG1 review, P0876 was redirected to target a Technical Specification rather than the IS—a significant procedural change.

6.2 Alternative Explanations

There are legitimate alternative explanations for the timeline disparity:

1. Genuine complexity: Specifying portable fiber semantics may genuinely be harder than specifying stackless coroutines. The issues around unwinding, TLS interaction, and debugger support are real.

2. Volunteer bandwidth: Kowalke and Goodspeed, working without corporate support, naturally had less capacity to rapidly iterate on feedback.

3. Committee bandwidth: Long-running proposals can experience review fatigue, and reviewers may unconsciously set higher bars as revisions accumulate.

4. Demand signaling: Major compiler vendors did not prioritize fiber support, which may reflect genuine uncertainty about demand rather than competitive positioning.

5. Technical advocacy: Nishanov’s effective presentations may simply have been better at communicating the value proposition of his approach.

6.3 The Core Question

What we can observe with confidence:

1. The committee’s 2015 commitment to pursue “both technologies” did not result in both technologies advancing at comparable rates.

2. The proposal backed by significant corporate resources succeeded; the proposal without such backing has not.

3. The resource disparity between the proposals was never systematically addressed.

The current process may systematically disadvantage volunteer-driven proposals. This pattern should concern those who care about WG21’s health as an institution.

7. Great Founder Theory Analysis

7.1 Institutional Dynamics

GFT describes how institutions develop internal dynamics that can diverge from their stated purposes. WG21’s stated purpose is to standardize facilities that benefit C++ users. The fiber saga raises questions about alignment:

• C++ users would benefit from having both stackless and stackful facilities available

• Corporate participants have interests that may or may not align with user needs

• The process produced an outcome where one approach advanced and the other stalled

The committee’s consensus-based process may naturally favor well-resourced proposals.

7.2 Succession Challenges in Boost

Boost historically served as C++’s “proving ground”—an institution that incubated standard library facilities. Boost.Context represents successful technical founding, but the standardization pipeline shows signs of strain:

• shared_ptr: Boost → C++11 ✓

• unique_ptr: Boost-inspired → C++11 ✓

• optional: Boost → C++17 ✓

• variant: Boost → C++17 ✓

• filesystem: Boost → C++17 ✓

• fiber_context: Boost → ??? ✗

The pattern suggests that Boost’s traditional role as a proving ground may be weakening relative to direct corporate influence.

7.3 The Founder Gap

Neither proposal had a true “founder” in the GFT sense—someone who could impose coherent vision across institutional boundaries. Nishanov had Microsoft’s backing but not committee authority; Kowalke had technical expertise but limited institutional power.

The difference: Nishanov’s “borrowed power” from Microsoft proved sufficient to advance through WG21. Kowalke’s borrowed power from Boost did not. Understanding why may help design better processes.

8. The Road Not Taken

8.1 What Standardized Fibers Would Enable

Had fiber_context been standardized alongside coroutines, C++ would have:

1. Transparent async composition: Existing synchronous code could run on fibers without modification

2. Simpler async programming model: No viral co_await markup

3. Foundation for green threads: As Go, Erlang, and Java (Project Loom) have demonstrated

4. Debugger and tooling standardization: As P0876 notes, standard fibers would enable standard tooling support

8.2 What We Got Instead

C++20 shipped coroutines without:

• std::task

• std::generator (arrived in C++23)

• Standard executors (P2300 arrived in C++26)

• Any practical usability out of the box

Users were directed to third-party libraries (cppcoro, folly::coro, libunifex) for basic functionality—the same libraries they would use for fiber support anyway.

9. Conclusion

The stackful coroutine saga invites reflection on WG21’s institutional processes. A well-understood, multiply-implemented, foundational primitive has spent over a decade in committee while a more complex alternative advanced with corporate backing.

The process produced an outcome that:

1. Did not fulfill the committee’s 2015 commitment to “pursue both technologies”

2. Advantaged the well-resourced proposal over the volunteer-driven one

3. Denied C++ users a valuable facility that exists in competing languages (Go goroutines, Java virtual threads, Erlang processes)

If WG21 is to serve the entire C++ community—not just its best-resourced participants—these patterns deserve attention. Misaligned incentives can produce suboptimal outcomes. Recognizing this is the first step toward building a more robust process.

10. Recommendations

1. Resource awareness: WG21 should recognize that volunteer-driven proposals face structural disadvantages and consider how to level the playing field.

2. Explicit interest disclosure: Committee members could voluntarily disclose when their employer has significant investment in a proposal’s domain—not as an accusation, but as useful context.

3. Commitment tracking: When the committee formally commits to pursuing multiple approaches, progress on each should be periodically reviewed.

4. Boost pathway review: Consider whether mature Boost libraries with extensive deployment history should face a streamlined standardization path.

5. fiber_context prioritization: P0876 has demonstrated extraordinary patience and responsiveness to feedback. The committee should prioritize its completion.

Acknowledgments

The authors thank the committee participants who shared their observations and reflections, and acknowledge Oliver Kowalke’s extraordinary persistence in maintaining both Boost.Context and the standardization effort for over a decade.

References

• N3708, N3985, N4024, N4397, N4398: Kowalke, Goodspeed. Stackful coroutine proposals (2013-2015)

• P0099R0-R1: Kowalke, Goodspeed. A low-level API for stackful context switching (2015-2016)

• P0876R0-R19: Kowalke, Goodspeed. fiber_context - fibers without scheduler (2018-2024)

• N4134, N4286: Nishanov. Resumable Functions (2014)

• P0057: Nishanov et al. Coroutines TS (2016-2018)

• N4232: Goodspeed. Stackful Coroutines and Stackless Resumable Functions (2014)

• P0991R0: Comparison of Stackful Coroutine Proposals (2018)

• Burja, S. (2020). Great Founder Theory.

• Chen, R. (2019). “Fibers aren’t useful for much any more.” The Old New Thing, Microsoft DevBlogs.

---

Revisions

• 2025-12-23: Reduced excessive disclaimers; let balanced presentation speak for itself.

• 2025-12-23: Clarified that “GFT” refers to Samo Burja’s Great Founder Theory framework.

• 2025-12-23: Softened tone to critique process rather than individuals; added alternative explanations for timeline disparity.

• 2025-12-24: Incorporated corrections from Nat Goodspeed: clarified Second Life fiber usage (client application, not scripting system), qualified travel funding statement, added stackless coroutine allocation costs and HALO optimization limitations, emphasized institutional interest asymmetry, added irony of Microsoft’s segmented stack critique.

• 2025-12-24: Converted proposal tables to lists for better readability.

---

We welcome corrections and additional perspectives from committee participants.