Can we support stackful coroutines / fibers? #602

Activity

1. CAD97 commented on Jan 29, 2026

   

   CAD97

   on Jan 29, 2026

   Contributor

   More actions

   FWIW, any function which could potentially execute a fiber switch probably needs to be considered unsafe, as I think it's unsound to do a fiber switch in combination with the LocalKey::with API:

   STATIC.with(|value: &_| {
       unsafe { may_suspend_fiber() };
       // original hardware thread may have exited
       Retag(&*value);
   });

   For the above, which explicitly holds a TLS slot's value's reference across a suspend point, to be sound, it requires the fiber runtime to guarantee that any thread which executes a fiber switch does not destroy TLS before all fibers have been terminated. (I do not know if this is a standard guarantee.)

   ---

   If we were to provide a compilation switch that ensures all TLS loads in the source are non-reorderable events, its potentially worth noting that the overhead in typical Rust code may be slightly lower than in typical C or C++ code, since the LocalKey API makes TLS fetches more visible than the thread_local storage-class specifier in C and C++, thus theoretically resulting in fewer source locations which directly use the thread local place when long-scoped LocalKey::with callbacks are used. Making every access through LocalKey emit a fresh TLS lookup seems less "surprising" than every mention of a #[thread_local] place being a forced TLS access.
2. RalfJung commented on Jan 29, 2026

   

   RalfJung

   on Jan 29, 2026

   Last edited by RalfJung

   MemberAuthor

   More actions

   I don't think we'd make this a compilation switch -- that would basically fork the language, which sounds bad. Either we do this via some form of annotation on the relevant functions, or we globally always assume any function may switch the fiber to a different thread.
3. Diggsey commented on Jan 29, 2026

   

   Diggsey

   on Jan 29, 2026

   More actions

   Windows provides FsAlloc/FsFree/etc functions which mirror TlsAlloc/TlsFree/etc but are local to the fiber rather than the thread.

   So, I'm not saying we should do this, but one option would be to resurrect Rust's pluggable concurrency of old. Similar to how you can compile with panic=abort, maybe you can compile with concurrency=fiber and all thread-local stuff is instead fiber-local.

   👍React with 👍1Reacted by comex
4. RalfJung commented on Jan 30, 2026

   

   RalfJung

   on Jan 30, 2026

   MemberAuthor

   More actions

   It is generally considered unsound to write code that needs a particular panic runtime to avoid UB; I would apply the same standard for concurrency runtimes.

   ---

   @Amanieu mentioned that corosensei avoids the TLS issue by never switching fibers from one thread to another. Does that prevent all possible incompatibilities with LLVM or could there still be optimizations that break stuff? LocalKey::with should be fine in that case I think.
5. Amanieu commented on Jan 30, 2026

   

   Amanieu

   on Jan 30, 2026

   Member

   More actions

   As far as I know, TLS access is the only potential issue with fibers in LLVM.
6. Darksonn commented on Feb 24, 2026

   

   Darksonn

   on Feb 24, 2026

   Member

   More actions

   I guess this also affects Tokio's loom testing framework, which relies on inline asm stack switching.

   👍React with 👍1Reacted by Ralf Jung
7. RalfJung

   added

   A-missingThere's something missing from the AM that prevents this from being possible.There's something missing from the AM that prevents this from being possible.

   on Apr 16, 2026