Comment by pjmlp
4 days ago
This looks kind of outdated, especially since we are on C++23 as latest approved standard, and co-routines would be a better approach since C++20.
Also how is the supposed Swift rewrite going on?
4 days ago
This looks kind of outdated, especially since we are on C++23 as latest approved standard, and co-routines would be a better approach since C++20.
Also how is the supposed Swift rewrite going on?
You're in luck: https://github.com/apple/foundationdb/blob/main/design/corou...
Thanks!
Coroutines aren't great, even C++26 is explicitly avoiding them for its foundational concurrency model.
In any case a good concurrency library doesn't need more than C++14.
In my understanding, senders/receivers is a more generalized concurrency model, but it has been designed to play well with coroutines.
Is it? Senders/receivers is based on NVidias experience using them on CUDA.
Naturally I haven't followed them that much, given how far away C++26 is from being usable for portable code.
Compilers are finally getting good enough with C++20 support for updating the default version.
Agree that the code examples look like communicating sequential processes (CSP) and/or async/await-style concurrency (i.e. co-routines in C++). To me this is not "Actors" at all. Actors don't "wait", they receive and send messages, and optionally specify the behavior for handling the next message.
What are actors doing between finishing processing the last message and receiving the next one?
yield to the event loop
9 replies →
[flagged]
Just because coroutines exist doesn’t mean everything should use them for concurrency.
Why would it be better? It’s pretty easy to set up threads in general.
Threads use more system resources than coroutines so it can be a big deal when you can potentially have thousands of them running.
Yeah I guess also depends on the problem space. For example, dedicated threads doing something versus a bunch of short-lived asynchronous tasks that need scheduling anyhow.
If a bunch of tasks need to be schedule best not to have to reinvent the wheel on that if possible.
If there’s longer running tasks the benefits probably are less noticeable.
The management to handle Threading and IO and not get it wrong is pretty high unless you’re using something like Rust because it guarantees you’re safe, vs letting the routine runtime management handle everything for you for free
Nah, coroutines/async/etc often lives in various threads (ie, the workers can schedule one of them on different threads during the lifetime and they live concurrently), so you still have all the issues of threading (+ new ones since things like thread-local variables aren't reliable if an async/coroutines moves threads between calls).
The main benefit is not having the cost of threads, f.ex. a default thread on Windows has something like 500k of stack iirc, scale that to 10000 concurrent requests and you're looking at 5gb of memory _just for stacks_, compared to a couroutine,etc that has perhaps a few kb's of usage (even if in deep stack-traces).
This is why we have stuff like io_uring these days, the bottleneck moved to the kernel calls (especially with Spectre style attacks) when concurrent costs in the applications went down.
6 replies →