I find rseq annoying because it is pointlessly designed to require every caller to write custom assembly code, for every target.
For very many use-cases, cpu-local variables (using the GS segment for x86) would suffice, which can then be used with ordinary atomic instructions without any asm. (Actually, even relaxed atomics are more expensive than needed, but unfortunately the language does not expose RMW primitives any other way. Fortunately this is a library problem and does not require every program to write its own asm. C standards people, please add `memory_order_volatile` and `memory_order_none` so we can use the APIs uniformly!)
The kernel already uses cpu-local variables internally, but it has the advantage of scheduling itself; userland processes have to pin everything to a single CPU (either statically, or doing its own scheduling somehow).
I find rseq annoying because it is pointlessly designed to require every caller to write custom assembly code, for every target.
For very many use-cases, cpu-local variables (using the GS segment for x86) would suffice, which can then be used with ordinary atomic instructions without any asm. (Actually, even relaxed atomics are more expensive than needed, but unfortunately the language does not expose RMW primitives any other way. Fortunately this is a library problem and does not require every program to write its own asm. C standards people, please add `memory_order_volatile` and `memory_order_none` so we can use the APIs uniformly!)
The kernel already uses cpu-local variables internally, but it has the advantage of scheduling itself; userland processes have to pin everything to a single CPU (either statically, or doing its own scheduling somehow).
librseq implements a bunch of higher-level RMW primitives that are sufficient for e.g. writing a linked list.