This is a great summary of the allocation argument, but you've buried the lede in your own edit. The 11 cycles number is meaningless for evaluating the proposal because the proposal mandates something that isn't measured in those 11 cycles.

Per-fiber exception state means on every resume() or resume_with() you have to save and restore the data underlying std::uncaught_exceptions() and std::current_exception(). The paper describes two strategies: (1) save/restore TLS on every switch, or (2) use upper_bound() on current stack pointer to look up which fiber is current. Strategy 1 adds a TLS read+write on every switch. Strategy 2 shifts cost to every exception query.

What's the actual number? 15 cycles? 30? 100 on Windows with SEH? The paper doesn't say.

22 revisions. this paper has been in committee longer than some of my coworkers have been alive

The paper claims:

A fiber switch takes 11 CPU cycles on a x86_64-Linux system using an implementation based on the strategy described in fiber switch using the calling convention

We've measured similar numbers with our own fcontext-based implementation. On Zen4 it's closer to 8-9 cycles. On Sapphire Rapids, 10-12. The calling-convention trick - save only the callee-saved registers (R12-R15, RBX, RBP on SysV) and swap the stack pointer - is well-understood and about as fast as you can get without compiler intrinsics.

What I want to know is the cost with the per-fiber exception state mandate baked in. The paper proposes TLS save/restore on every switch OR an upper_bound() lookup on current_exception()/uncaught_exceptions() calls. In our codebase, fiber switches are on the critical path. Even 5ns extra per switch matters when you're doing 10M+ switches/sec on a market data feed.

The paper needs actual benchmark numbers for both strategies before LWG can make an informed decision.

Remember when we were told coroutines would solve everything? P2300 and sender/receiver would give us async I/O and it would be beautiful? Now we need fibers because coroutine frame allocation is a problem (P4003R0), and coroutines waiting on senders need to propagate a custom allocator through every parameter list (P4007R0). Classic.

Let me lay out the timeline because the process story here is remarkable.

LWG tentatively approved library wording in St. Louis, June 2024. CWG finished initial core wording review in Tokyo, March 2024 - with one change request (per-fiber exception state). EWG approved that change 6/8/3/0/0 in St. Louis. Then EWG requested implementation experience. Wroclaw: presented it. Microsoft asked for time. Hagenberg: Microsoft conceded it's implementable, but arrived too late for EWG. Sofia, June 2025: EWG forwarded to CWG/LWG for C++26 with SF 10 / F 14 / N 4 / A 5 / SA 1.

And then CWG and LWG ran out of time.

The paper quotes P1000R6:

Just wait a couple more meetings and C++ will be open for business and can be the first thing voted into the C++ working draft.

This is the promise of the train model. A paper that has been through 22 revisions, had wording approved by two groups, got forwarded by a third, and still missed the train because of scheduling. Now it's C++29. The authors are understandably frustrated, and they are being polite about it.

The 5 against + 1 strongly against in the EWG vote is worth noting though. That is not insignificant opposition for a paper at forwarding stage. The concerns are real even if the majority is clear.

I want to push back on how the paper handles P3620R0's concerns. The paper states:

At a high level, P3620R0 appears to argue that unless fibers are appropriate for all use cases, they must not be available for any use case.

This is a straw man and the authors probably know it. P3620R0 raises three specific, technical concerns:

1. thread_local is shared between fibers on the same thread. The paper says "std::thread was introduced despite this problem." But thread_local was literally designed FOR threads. Fibers break the expectation. The paper's own TLS section acknowledges the problems but waves them away.

2. Deadlock potential when holding a mutex across a fiber switch. The paper again says "C++20 coroutines have the same problem." True, but coroutines have a visible suspension point (co_await). With fibers, ANY opaque function call might suspend. That is a qualitative difference in audibility.

3. Cross-thread resumption is forbidden (removed in R10). But many production fiber schedulers - including brpc's bthread - DO migrate fibers between threads. The standard facility is strictly less capable than several of the deployed systems the paper cites as evidence of demand.

Dismissing these as "fibers aren't appropriate for all use cases so they can't be available for any" is not engaging with the actual technical objections. A stronger paper would steelman P3620R0 and explain why the tradeoffs are still worth it.

so this is basically green threads but they don't want to call it green threads

The API design here is genuinely interesting, and I think most people scrolling past are missing what makes it clever.

The key insight: resume() returns a synthesized fiber_context representing the calling fiber. So the fiber you switch to receives a handle to the fiber that just suspended. And resume() is rvalue-ref-qualified, so calling it empties the object. You literally cannot hold two handles to the same fiber.

fiber_context f{[](fiber_context&& caller) {
    // caller is the fiber that called f.resume()
    caller = std::move(caller).resume();
    // back again, caller updated
    return std::move(caller);
}};
f = std::move(f).resume();
// f now represents the suspended lambda

The type system prevents the misuse. If you have the object, you own the only handle. Once you call resume(), the object is empty. No double-resume, no dangling handles, no reference counting. Move-only + rvalue-ref-qualified is brutal and correct.

But the learning curve is steep. The "synthesized fiber_context" concept requires understanding that resume() both suspends the caller AND creates a new object representing that caller. It is symmetric switching - no caller/callee relationship. Compare to Go's goroutines where the scheduler is invisible, or coroutines where co_await is the explicit suspension point. fiber_context makes you be the scheduler, which is the point - and the barrier to adoption.

ok but can we make fiber_context constexpr

Embedded developer here. The explicit-stack constructor is the reason I care about this paper:

fiber_context(F&& entry, span<byte> stack, D&& deleter);

On our STM32 targets, we cannot afford dynamic stack allocation. We preallocate fixed-size stacks from a pool. The span constructor is exactly right for this use case.

But the paper says: "If at any time during the life of a fiber the data storage required to track its invocation sequence exceeds the size() of that span, the behaviour is undefined." No guard pages in our environment. No MMU in many cases. Stack overflow is silent corruption.

11 cycles for a context switch is appealing for our RTOS replacement use case. But UB on stack overflow, with no way to detect it, is the worst possible answer for safety-critical embedded systems. An implementation-defined hook for stack overflow detection would make this paper much more attractive for our domain.

laughs in compile times

at least <fiber_context> is presumably not going to be a compile-time disaster like <ranges>. it's one class with like 6 member functions.

can someone ELI5 what a fiber is? I thought threads were the things you use for concurrency

One more thing that bothers me about the proposed API. Destroying a non-empty fiber_context calls terminate:

If empty() is false, terminate is invoked ([except.terminate]).

This is more aggressive than std::thread, which gives you detach() and join() as escape hatches. With fiber_context, if you forget to properly wind down a fiber before the handle goes out of scope, your program dies. Period.

The paper includes an autocancel wrapper class in Appendix D - roughly 60 lines of non-trivial code - just to safely manage fiber lifetimes. If the "building-block primitive" requires a 60-line RAII wrapper to avoid calling terminate, maybe the building block needs another look at its lifecycle design.

I get the reasoning: you can't safely destroy a suspended fiber's stack because of RAII objects that might hold resources. And detach doesn't make sense without a scheduler. But "get it wrong and your program terminates" is a sharp edge for something intended to be foundational.

Edit: to be fair, std::jthread partially addressed the same problem for threads. Maybe a std::jfiber is the answer here too, but that's a separate paper and a separate decade of committee time.