Stackful Coroutines in WG21: A Case Study in Institutional Neglect and Corporate Influence

Great Founder Theory in C++

Document number: P3XXX

Date: 2025-12-17

Project: Programming Language C++, WG21

Reply-to: [Author]

Stackful Coroutines in WG21: A Case Study in Institutional Neglect and Corporate Influence

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. 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 name the key individuals, corporations, and institutional dynamics responsible for this outcome. We also examine allegations—raised by committee participants who requested anonymity—that Microsoft actively worked to block or delay stackful coroutines to protect their stackless coroutine investment, and assess the evidentiary strength of this accusation.

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:

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:

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.

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 evangelist for stackless coroutines. His CppCon presentations (2014-2019) consistently emphasized stackless coroutines’ advantages while dismissing stackful approaches. 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 framing positioned scalability as the paramount concern, implicitly casting stackful coroutines as obsolete. Raymond Chen (also Microsoft) later published a blog post titled “Fibers aren’t useful for much any more,” citing Nishanov’s work and declaring that “the initial excitement was gradually met with the realizations that fibers are awful.”

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 for Second Life’s scripting system) provided real-world deployment experience.

4.4 The Asymmetry

The resource asymmetry is glaring:

• Nishanov: Full-time Microsoft employee, compiler team access, corporate travel budget, implementation shipping in production compiler since 2013

• Kowalke/Goodspeed: Volunteer effort, no compiler team access, personal resources for travel, implementation in Boost only

5. Corporate Dynamics

5.1 Microsoft’s Investment

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

This investment created institutional momentum. A Microsoft employee attending SG1 meetings represents Microsoft’s interests even without explicit coordination.

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. The Blocking Allegation

6.1 The Claim

Multiple committee participants, speaking on condition of anonymity, have alleged that Microsoft representatives actively worked to delay or block stackful coroutine proposals to protect their stackless coroutine investment. The specific allegations include:

1. Procedural obstruction: Raising objections that required repeated revision cycles without providing clear resolution criteria

2. Scope expansion: Insisting that fiber proposals address increasingly complex edge cases (exception handling, thread-local storage, stack unwinding) that were not required of the stackless proposal

3. Implicit lobbying: Signaling to other committee members that Microsoft viewed the proposals as competitive rather than complementary

4. Resource asymmetry exploitation: Leveraging the ability to send multiple representatives to meetings while Kowalke/Goodspeed had limited attendance

6.2 Evidence Assessment

We must assess this allegation rigorously. The evidence falls into several categories:

Circumstantial evidence supporting the allegation:

1. Timeline disparity: Stackless coroutines advanced from proposal to standard in ~6 years; stackful coroutines have stalled for 12+ years despite the 2015 “both technologies” finding.

2. Asymmetric requirements: The stackful proposal has been required to resolve complex unwinding semantics that were never required of the stackless proposal. P0876’s revision history shows repeated redesigns of stack unwinding, exception propagation, and cancellation mechanisms.

3. Nishanov’s public framing: His presentations and papers consistently positioned stackful coroutines as inferior (”fibers are awful”), creating a hostile reception environment.

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 delay tactic that was not applied to stackless coroutines.

5. Missing from C++23 and likely C++26: Despite 19 revisions and a decade of committee engagement, fibers have not shipped and show no signs of imminent adoption.

Evidence against the allegation:

1. No smoking gun: There is no documented statement from Microsoft employees explicitly opposing stackful coroutines for competitive reasons.

2. Legitimate technical concerns: The issues raised about fiber unwinding, TLS interaction, and debugger support are real technical challenges, even if asymmetrically applied.

3. Committee dynamics: WG21’s consensus-based process allows any participant to raise concerns; Microsoft is not uniquely empowered to block proposals.

4. Alternative explanations: The disparity might reflect:

   • Kowalke/Goodspeed’s limited bandwidth as volunteers

   • Genuine complexity in specifying portable fiber semantics

   • Committee fatigue with long-running proposals

   • Lack of demand signaling from other major vendors

6.3 Assessment

The evidence is suggestive but not conclusive. The pattern of asymmetric treatment is documented and undeniable. Whether this reflects deliberate obstruction or emergent institutional bias is impossible to determine from public records.

What can be said with confidence:

1. Microsoft had clear incentive to see stackless coroutines succeed and stackful coroutines fail or be delayed.

2. The outcome perfectly aligned with Microsoft’s interests.

3. The committee’s stated intention to pursue “both technologies” was not honored.

4. The resource asymmetry between the proposals’ champions was never addressed.

The allegation cannot be proven, but neither can it be dismissed. The circumstantial case is strong enough to warrant concern about WG21’s vulnerability to corporate influence.

7. Great Founder Theory Analysis

7.1 Institutional Capture

GFT describes how institutions become captured by interests that subvert their nominal purpose. WG21’s nominal purpose is to standardize facilities that benefit C++ users. The fiber saga suggests capture by vendor interests:

• Microsoft benefits from stackless coroutine adoption (validates their investment, drives Visual Studio/Azure usage)

• C++ users would benefit from having both facilities available

• WG21 delivered only Microsoft’s preferred outcome

7.2 Succession Failure in Boost

Boost historically served as C++’s “proving ground”—a founder-led institution that incubated standard library facilities. Boost.Context represents successful technical founding, but the standardization pipeline has broken:

• 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 power to drive standardization has decayed, replaced by 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 no institutional power.

The difference: Nishanov’s “borrowed power” from Microsoft was sufficient to advance through WG21. Kowalke’s borrowed power from Boost was not.

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 represents a failure of WG21’s institutional purpose. A well-understood, multiply-implemented, foundational primitive has been blocked from standardization for over a decade while a more complex, less complete alternative was fast-tracked with corporate backing.

The evidence suggests—but does not prove—that Microsoft’s interests influenced this outcome. What is undeniable is that:

1. The committee’s 2015 commitment to “pursue both technologies” was not honored

2. The resource asymmetry between corporate-backed and volunteer-driven proposals produced predictable results

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

Whether through deliberate obstruction or emergent institutional bias, the outcome serves corporate interests over user interests. This should concern anyone who believes WG21 exists to serve the C++ community rather than its most powerful corporate participants.

10. Recommendations

1. Resource equalization: WG21 should establish mechanisms to support volunteer-driven proposals against corporate-backed competition.

2. Explicit conflict of interest disclosure: Committee members should disclose when their employer has commercial interest in a proposal’s outcome.

3. Accountability for “both technologies” commitments: When the committee formally commits to pursuing multiple approaches, progress should be tracked and reported.

4. Fast-track for mature Boost libraries: Facilities with extensive Boost deployment history should face a lower standardization burden, not a higher one.

5. Immediate fiber_context adoption: P0876 should be adopted into C++26 without further delay. The design is mature, the implementation exists, and the community has waited long enough.

Acknowledgments

The authors thank the committee participants who shared their observations on condition of anonymity. We also acknowledge Oliver Kowalke’s extraordinary persistence in maintaining both Boost.Context and the standardization effort for over a decade without corporate support.

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.

---

The views expressed in this paper are those of the authors and do not necessarily reflect the positions of any organization. We welcome corrections and additional evidence from committee participants.