4 ms·
I'm sure why it's a "recipe for disaster"? The old API is very crufty and now that the problem is stable and well understood, the kernel developers would prefe
by rwmj 3y ago
I'm sure why it's a "recipe for disaster"? The old API is very crufty and now that the problem is stable and well understood, the kernel developers would prefer to start with a cleaner API. Not least because adding (eg) NUMA support to the existing API would be piling hacks on hacks. Take a look at the old API and wonder where you would pass the NUMA struct pointer:
https://man7.org/linux/man-pages/man2/futex.2.html https://man7.org/linux/man-pages/man2/futex.2.html
Another special feature of futexes is that no one ever used them directly (not least because they are subtle to use correctly). Instead a few libraries used them and implemented standard APIs on top (pthread etc). Libraries like glibc and other libcs, and probably a few languages that have an aversion to using glibc. So the specific use cases of the old API are well known and scoped.
- tialaramex 3y ago> probably a few languages that have an aversion to using glibc. You don't need an aversion to the whole glibc to consider that "Just eat some archaic data structure" is too expensive for a language that cares about performance. Rust's Mutex is defined over futex on Linux and some other Unix systems, srw locks on Windows because if you write it in terms of the pthread structure or the equivalent for Windows it's slower and much bigger.
- rjsw 3y agoSBCL can use futexes directly.