Our great sponsors
-
tokio
A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
ck
Concurrency primitives, safe memory reclamation mechanisms and non-blocking (including lock-free) data structures designed to aid in the research, design and implementation of high performance concurrent systems developed in C99+.
-
I saw this in 2017. Unfortunately, not much activity now. https://github.com/sustrik/libdill/commits/master
Might be fun to play with, but I wouldn't rely on it. Generally, better off with libuv for existing projects or Rust for greener fields where lifetimes are checked and safe concurrency is much easier.
You can do it for Rust threads - but it gets tricky with Rust coroutines (async functions).
I made an attempt of implementing it for async Rust in
https://github.com/tokio-rs/tokio/issues/1879
with a concrete implementation in
https://github.com/tokio-rs/tokio/pull/2579
It mostly follows the Kotlin model of structured concurrency. However it has its sets of drawbacks due to Rust Futures being immediately cancellable, which then leads to problem if a parent task gets simply dropped.
In order to handle that case better I've written a proposal for async functions that run to completion with https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-asy... . However that is all theoretical, and might never see the light of the day.
There are plenty of practical solutions to the safe memory reclamation problem in C. The language just doesn't force one on you.
From epoch-based reclamation (https://github.com/concurrencykit/ck/blob/master/include/ck_..., especially with the multiplexing extension to Fraser's classic scheme), to quiescence schemes (https://liburcu.org/), or hazard pointers (https://github.com/facebook/folly/blob/master/folly/synchron..., or https://pvk.ca/Blog/2020/07/07/flatter-wait-free-hazard-poin...)... or even simple using a type-stable (https://www.usenix.org/legacy/publications/library/proceedin...) memory allocator.
In my experience, it's easier to write code that is resilient to hiccups in C than in Java. Solving SMR with GC only offers something close to lock-freedom when you can guarantee global GC pauses are short enough... and common techniques to bound pauses, like explicitly managed freelists land you back in the same problem space as C.
There are plenty of practical solutions to the safe memory reclamation problem in C. The language just doesn't force one on you.
From epoch-based reclamation (https://github.com/concurrencykit/ck/blob/master/include/ck_..., especially with the multiplexing extension to Fraser's classic scheme), to quiescence schemes (https://liburcu.org/), or hazard pointers (https://github.com/facebook/folly/blob/master/folly/synchron..., or https://pvk.ca/Blog/2020/07/07/flatter-wait-free-hazard-poin...)... or even simple using a type-stable (https://www.usenix.org/legacy/publications/library/proceedin...) memory allocator.
In my experience, it's easier to write code that is resilient to hiccups in C than in Java. Solving SMR with GC only offers something close to lock-freedom when you can guarantee global GC pauses are short enough... and common techniques to bound pauses, like explicitly managed freelists land you back in the same problem space as C.