I don't think "fiber" has a universally agreed definition, which makes these things super confusing to read without clarification. It's hard to come up with a good definition and stick to it because people keep coming up with new variations.

An interesting case is a different Google fiber library, not open-sourced but described in a public talk. [1] Real kernel threads but (mostly) scheduled in userspace via new syscalls [2] that suspend the current thread and unsuspend a userspace-chosen other thread. The idea is that most of the overhead of kernel threads is the scheduling and userspace has the ability to make a quick good choice. [3] Thus you can get most of the CPU performance of an async implementation but the relatively easy-to-read callback-free code of a threaded implementation. Anyway, people can disagree on what to call such a combination.

[1] https://www.youtube.com/watch?v=KXuZi9aeGTw

[2] the rseq stuff described in that talk has been upstreamed [4] but the switchto stuff still hasn't.

[3] I'm not sure if the performance argument is as strong since the Meltdown/Spectre mitigations added to the performance cost of any syscall.

[4] https://www.efficios.com/blog/2019/02/08/linux-restartable-s...

Personally I recommend Distinguishing coroutines and fibers (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n402...)

In short:

- The key difference between fibers and kernel threads is that fibers use cooperative context switching

- When a coroutine yields, it passes control directly to its caller (or, in the case of symmetric coroutines, a designated other coroutine).

- When a fiber blocks, it implicitly passes control to the fiber scheduler. Coroutines have no scheduler because they need no scheduler

Is that kind of like how gevent for Python works? I thought they were coroutines but there's a scheduler, I think.

Fibers can be built (and according to the paper, in C++ Boost they are) on top of coroutines, and that's essentially what both gevent and asyncio do.

Not sure about the term, but I know Windows has had them for almost two decades[1], so hardly a newfangled concept.

Here's[2] a fun/interesting 15 year old blog post explaining some of the use cases and pitfalls of using Win32 fibers.

[1]: https://jeffpar.github.io/kbarchive/kb/128/Q128531/ (CreateFiber)

[2]: https://docs.microsoft.com/en-us/archive/blogs/larryosterman...

"Fibers" is a term for manually-scheduled threads that was used in Windows at least since Windows 2000. Niche feature, but it was fully documented and all.