[bicarbonato]

Setting aside certain implementation details, here's the basics:

Kernel Threads (aka threads): OS-Level and preemptive.

Green Threads (aka lightweight threads, virtual threads or goroutines): User-level and preemptive.

Fibers: User-level (sometimes OS-level or offered as a OS library, like in Windows) and cooperative.

Coroutines: User-level and cooperative.

[dwaite]

The devil's in the implementation details though. The operating system may provide both fully-preemptive threads on which to schedule user space cooperative threads (scheduling on system call). At that point green threads (e.g. threading implemented by a virtual machine on top of the operating system) do not provide the same value. This is actually why Green threads were effectively pulled out of Java for a few decades.

Fibers are distinct in that they have no scheduling and are code being run on a thread - if the thread is preempted, it will resume on that same thread. Unlike cooperative threading, they must explicitly yield.

Coroutines have such varying implementations that you would need to define requirements to know if they count as fibers or not - for instance, whether you mandate a C-compatible stack.

[foota]

There's one thing missing here, whereas fibers are cooperative, they have a user space scheduler deciding which fiber to switch to on a thread when you yield, coroutines specify who they're yielding to.

[gpderetta]

As per article, Windows fibers literally have a SwitchToFiber call and come with no scheduler. So there is really ni difference.

[foota]

You'll notice the function's documentation is "Schedules a fiber. The function must be called on a fiber." so while it may not be a literal difference (after all they're both semi-user space), they are difference systems to use, but they're both roughly at the same level of "power".

If you're not using a scheduler with fibers then I'd argue you shouldn't be calling it a fibers system (and rather coroutines), since otherwise it's a distinction without a difference.