stack-switching
gruvi
| stack-switching | gruvi | |
|---|---|---|
| 2 | 1 | |
| 112 | 94 | |
| 8.9% | - | |
| 9.4 | 10.0 | |
| 2 days ago | over 6 years ago | |
| WebAssembly | Python | |
| GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
stack-switching
-
WasmFX: Effect Handlers for WebAssembly
I first heard of algebraic effects in a presentation about Unison recorded at Strangeloop. Realizing that exceptions, async, generators, and continuations could all be unified and implemented on top of one language feature was mind expanding.
It looks like the juicy details are in the Explainer:
https://github.com/WebAssembly/stack-switching/blob/main/pro...
-
Fiber in C++: Understanding the Basics
"Fibers", "green threads", "stack switching", "cooperative multitasking" are essentially all the same thing, they all rely on being able to switch to a different stack within the same OS thread. As such they can be implemented either in user space or by the OS.
Only downside of the technique is that it cannot be implemented in WASM, because WASM has separate data- and call-stacks and the call stack is not accessible from within the WASM virtual machine (while 'async-await' which relies on code transformation can be implemeneted in WASM just fine).
There is a 'stack-switching proposal' for WASM though, but I don't know how what's the state of that:
https://github.com/WebAssembly/stack-switching
gruvi
-
Fiber in C++: Understanding the Basics
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.
What are some alternatives?
marl - A hybrid thread / fiber task scheduler written in C++ 11
context
ghost-userspace
llvm-project - The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
cgreenlet - Coroutines for C/C++
assembly - assembly projects