context VS cgreenlet

https://github.com/boostorg/context/blob/6fa6d5c50d120e69b2d...

...and this causes problems, because it can't guarantee that all fields are initialized or switched successfully: https://lists.boost.org/boost-bugs/2014/10/38476.php

Microsoft continually adds and changes fields in the TIB with each new release of Windows. Attempting to implement fibers manually is a ticking time bomb that should never be used in production.

Marginally disagree. Lots of optimization work takes advantage of knowing how the ABI works. Knowing you can pass two register returns on SysV is a particularly common optimization point. Writing context switching routines that can be reliably ported (ex, boost-context) requires this consistency of ABI. As a final example, cache locality optimizations require the ability to reason about ABI layout.

A disadvantage to the ‘no function coloring’ in fibers is that it makes lockless programming harder. A nested function call can switch from under you without your knowledge, making it hard to know where the preemption points are and whether to take locks when making updates to shared state. With function coloring you know exactly whether a function might switch or not.

I’ve programmed both fiber based systems and coroutines. I even created my own fiber libraries for Python (https://github.com/geertj/gruvi) and C++ (https://github.com/geertj/cgreenlet, mostly an experiment, and incorrectly named coroutines for C++ while it’s really fibers). In the Python version I experimented with some features to help you know whether a nested function might switch.

In the end, for me and for the problem domains I worked in, the explicit async/await co-routine style wins over fibers. It gives you most of the performance and memory benefits of user mode switching while keeping your code mostly lock free.