<When WhatsApp pushed the Erlang BEAM virtual machine to its limits on 100+ core machines, the system choked. As detailed by Robin Morisset, idle threads trying to steal work spent all their CPU cycles fighting over the global runq_lock5>
A simple burst of memmap + soft fault with 100 or 1000 threads on a normal laptop would tell you that thread contention is real and cache locality gets destroyed. Couple that with pinned threads. You can see the latency increase by increasing thread count. Add to that the motherboard interconnect tax for numa systems. Work stealing is not the way for increasingly many workloads on modern hardware.
Recently we built Dip, our in-house ephemeral + parallel database, and we went with may coroutines + work pinning to the same thread which also nicely becomes numa aware via architecture.
Increasing threads beyond system's hardware cores/threads resulted only in marginal gains of a couple of milliseconds worth of differences on huge workload with large increase in memory (thread stack) used by the massive number of threads.
There are some fundamental assumptions in the Rust async system:
- The program is mostly I/O bound.
- All tasks have equal priority.
If your program isn't like that, the Tokio model is a bad match to the problem.
Real time control is not like that. MMO and metaverse game programs are not like that. Most web stuff is, but that's a special case. A big special case, but a special case.
To be fair, the Rust async model itself was intentionally designed not to be prescriptive in the way you describe. You can build, and there exists, different task executors that can handle things like priority and many other execution models.
Async is just a way to describe a tree of concurrent tasks that may depend on (wait on) each other at certain points. It is mostly declarative.
Tokio has taken over as the default choice, but there's a reason why it's not part of the standard library, it is not meant to be the only choice.
Outside of Embassy in embedded, tokio is the only realistic choice though, because it is likely that any third party async crate has a dependency ok it already. Yes, smol, monio, glommio etc exist, but they are marginalised (and as far as I can tell they don't really help that much with mixed IO / compute workloads).
In fact, async/await in Rust falls apart with a mixed IO / compute workload since scheduling is cooperative. As soon as you want preemption (most of the time for what I do), it is not the right choice.
Seeing how embassy (embedded async rust) handles preemption reinforces this: it uses a separate scheduler per preemption level. This works fine, but is a bit clunky. Basically you are at this point just using async to help write a state machine per preemptive thread, which can be useful for some code patterns (in particular those common in embedded, where you are often waiting for IO). But to talk between threads you are back to channels, mutexes etc.
I was looking forward to checking out Project Tina until I realised it was a completely different language. Classic story. Surely you can build a thread-per-core message passing concurrency framework in Rust, the language is designed to allow such alternatives.
Is Project Tina a bit like the Actor Model, but having actors pinned to cores?
And I don't understand how Tina deals better with the problem of compute-heavy tasks blocking the thread. It looks to me like it is also cooperative concurrency per core, and if one Isolate runs for a long time the other Isolates in that core will not be able to handle their messages.
1. It's not reasonable to expect the application layer to carefully partition its work into "I/O heavy" and "CPU heavy" parts.
2. It's not reasonable to queue up an arbitrary amount of work without back-pressure.
I haven't used Tokio much, but if it falls prey to these pitfalls, it would make me pause before adopting it.
I think there are probably ways of using Rust async that don't fall prey to these. Maybe not so much with network servers (I haven't written that many of those), but models where you are evaluating a graph and have more control over how new work is added to the system.
The suggested alternative is interesting, I was expecting a Rust library though, but it's an Odin one. What's missing are any sort of benchmarks or proof of the claims that it will scale beyond the issues the article discuss.
This is nonsense. Tokio was built for I/O, not crunching numbers. Most programmers know to use spawn_blocking to crunch 10MB JSON, if needed.
Additionally, the proposed workload per thread model will be orders of magnitude slower than Tokio for I/O-bound workloads, which most applications are.
I am not really sure how much yet another post complaining about async/await that ends with “thread-per-core is the way to go” adds to this discussion. Granted I’m both an Erlang programmer and a big fan of Tokio and Rust’s async/await implementation in general and I think this post and many others like it betray a fundamental misunderstanding of these technologies so I am probably biased.
When I learned about async/await when it came out with .NET, they put tremendous amount into explaining that async/await is not concurrency. But that was in time when you did a training when a new version of your programming stack came out and you did not consume knowledge in 30s snippets.
This is silly or just AI slop post? Because using a Go quote as an example of doing something right in the arena is laughable at best where it has the same problems, more magic, and worse observability.
The punchline seems to be something like the LMAX disruptor style which is genuinely good for some things, but if you have I/O loops like the illustration shows you can easily block that loop with some long running function.. so you have the same cognitive load as managing thread pools or async pools or disruptors..
I can hate Rayon and Tokio as much as the next guy generally I can empathize with problems they cause. But largely either it's a skill issue.
Or you are just trying to squeeze lemonade from stones, ala, they aren't meant to do what you are doing.
Tokio especially is extremely widely used for all kinds of things it doesn't work well for.
Sure I could improve it add or tune some primitives but I am honestly considering writing my own. And so should others.
I feel like we are all too bound in Rust ecosystem suddenly to Tokio and Rayon because we don't want to blame and acknowledge the libraries just don't work for what we want to use it for.
And library authors don't consider these usecases and bug important enough to actually fix it in a ergonomic way.
I think it's important to understand how we got here and a lot of it has to do with serving network requests or RPCs.
The first Web servers used CGI (Common Gateway Interface). This spawned an entire program (process) per request and had obvious overheads. This led to some optimizations (eg FastCGI, ISAPI/NSAPI) to reduce the overhead. This was the era of Perl scripts being popular.
Then came the model of having a persistent state across requests. Java servlets were a big example of this. Given the cost of exec'ing a process, this was a big deal. But then you've immediately created an environment where multiple threads were accessing the same resource and you could leak resources. There were other variants like CORBA.
Now this was abotu the time of the birth of PHP. PHP was revolutionary because it had a stateless core that allowed shared hosting environments, which were exceptionally cheap for the time (even though they had security issues). But the idea is that you avoided the threading issues of a persistent environment and didn't really have resource leaks because everything got torn down. Of course PHP had other issues. But this was a big deal because things like the initialization of a JVM class loader, for example, was relatively expensive and you had to tune Java servers around performance and STW GC pauses.
None of the above really has anything to do with programming languages other than people learned (or didn't learn) just how hard writing multithreaded code is, something that is true to this day and you absoultely want to avoid it if possible. It is incredibly difficult to get right in an era of cores, threads, different L1/L2 caches, out-of-order proccessing, branch prediction, etc etc etc. And your code may have to run on multiple architectures.
Now Go chose to get around this issue with goroutines and channels. I personally think these are a bad abstraction, particularly because buffered channels are used without understanding the impact (leading to deadlocks), you can have exploding goroutine sttacks and using unbuffered channels is a strictly inferior (IMHO) async/await abstraction.
I actually think that Facebook's Hack has basically the almost perfect async/await. The whole idea of async/await is that you get the benefits of the PHP model of being single-threaded in your own application code and you can tear down your environment when you're done. Any IO goes through async API functions.
Now how does the scheduler manage threads, exhaustion, etc in this environment? Honestly? I have no idea. It just basically works. So maybe the Tokio issue is that the scheduler itself is blocked, which seems to be the case from this article. That does seem like a flaw but a fixable one.
I get the whole colored function criticism but the reality of using Hack to serve HTTP requests is that everything is async anyway so it seems to be a non-issue in practice. You can if you really need to call call an async function from a non-async function with a blocking function but that's not best practice.
I do know that thread pools, particularly multiple thread pools, is not the answer.
Your history is all valid, but I don't think it really hits on the main motivations for how we got here.
Thread per request works perfectly fine if your application is CPU constrained.
However the observation was made, that most web applications are IO constrained, the majority of the time spent serving a web request is spent waiting for a database or downstream API.
Since most of the threads are idle waiting, your application needs many threads to optimally utilize the servers resources.
There was a perception(valid or not) that OS threads have too much memory and scheduling overhead.
Nginx came out using async io, and it could handle much more concurrent requests than apache, which used a threaded model, it sparked a lot of interest in different kinds of application managed scheduling.
It inspired initiatives like the reactive manifesto[0], which spawned tools like RXJava.
That's an informative overview. Somewhere in the story was Node.js and libuv, the callback style, promises, and the popularization of the async/await paradigm. Not sure if there was a direct influence on Rust's async libraries, but I imagine it affected how some people think what an intuitive async syntax might look like.
I've been thinking similar thoughts recently, in that I am not sure that a function call is the best way to model asynchronicity. Io-uring in particular feels much more suited to a req/res type model, which has the benefit that you can make a single threaded state machine the core of your app - very pleasant to test and reason about.
I'd draw the analogy to RPC; it's a leaky abstraction because HTTP is fundamentally a different thing than a function call. I'd argue that event loops are a different thing as well.
I agree that a request-response model can be quite ergonomic for concurrency. I've used this pattern in quite a few Rust projects in a somewhat ad-hoc manner.
It's a bit like having a system composed of microservices (nanoservices?) that communicate via function calls.
It sounds a lot like the actor model, but I always found the classic architecture too limiting: requiring every actor to be a single-threaded message processor, instead of being able to handle requests concurrently. It's not too different from classic object-oriented design either, with singleton services.
In some project I've called my concurrent services Gods just to have a bit of fun with it :)
In a cooperative runtime like Rust’s Tokio or Node.js, the thread does not yield until it hits an await point.
This is just because JS is single threaded. Python has the Global Interpreter Lock, which makes it effectively single threaded too. That means you don’t have to deal with true parallelism, and critical sections, semaphores etc. It’s like Ethereum: only one thing happens at a time.
But you don’t have to parse JSON without yielding. You can make anything async by just using setTimeout once in a while. Here is one such implementation: https://www.npmjs.com/package/yieldable-json
The guy may as well have said while(1) locks up Node.
Now they get into multithreaded work-stealing, and isolates. But the solution in Node is to spin up multiple processes and pass messages between them. This is approaching the Erlang actor model, and is also shared-nothing. They even say "the schedule is a single-threaded loop per core" and "all cross-core communication occurs via the messaging subsystem".
This can also be achieved in most other single-threaded languages, too. Python with asyncio, for instance.
Tina may provide a nice opinionated implementation with bounded queues and deterministic scheduling, but those are architectural choices rather than evidence that async/await itself has failed.
The title of the post is "Tokio/Rayon Trap" - those are two very well known Rust libraries.
(in case you missed it, authors mention them later and explain what they do: "Use Tokio for I/O, and send CPU-bound work to a dedicated thread pool like Rayon.")
Authors have whole section ("The Work-Stealing Myth") on Erlang.
Author's proposed solution ("Project Tina") is a new programming language written in Odin.
How on earth do you read this all and start talking about Javascript problems instead?
A simple burst of memmap + soft fault with 100 or 1000 threads on a normal laptop would tell you that thread contention is real and cache locality gets destroyed. Couple that with pinned threads. You can see the latency increase by increasing thread count. Add to that the motherboard interconnect tax for numa systems. Work stealing is not the way for increasingly many workloads on modern hardware.
Recently we built Dip, our in-house ephemeral + parallel database, and we went with may coroutines + work pinning to the same thread which also nicely becomes numa aware via architecture.
Increasing threads beyond system's hardware cores/threads resulted only in marginal gains of a couple of milliseconds worth of differences on huge workload with large increase in memory (thread stack) used by the massive number of threads.
- The program is mostly I/O bound.
- All tasks have equal priority.
If your program isn't like that, the Tokio model is a bad match to the problem.
Real time control is not like that. MMO and metaverse game programs are not like that. Most web stuff is, but that's a special case. A big special case, but a special case.
Async is just a way to describe a tree of concurrent tasks that may depend on (wait on) each other at certain points. It is mostly declarative.
Tokio has taken over as the default choice, but there's a reason why it's not part of the standard library, it is not meant to be the only choice.
In fact, async/await in Rust falls apart with a mixed IO / compute workload since scheduling is cooperative. As soon as you want preemption (most of the time for what I do), it is not the right choice.
Seeing how embassy (embedded async rust) handles preemption reinforces this: it uses a separate scheduler per preemption level. This works fine, but is a bit clunky. Basically you are at this point just using async to help write a state machine per preemptive thread, which can be useful for some code patterns (in particular those common in embedded, where you are often waiting for IO). But to talk between threads you are back to channels, mutexes etc.
Is Project Tina a bit like the Actor Model, but having actors pinned to cores?
And I don't understand how Tina deals better with the problem of compute-heavy tasks blocking the thread. It looks to me like it is also cooperative concurrency per core, and if one Isolate runs for a long time the other Isolates in that core will not be able to handle their messages.
1. It's not reasonable to expect the application layer to carefully partition its work into "I/O heavy" and "CPU heavy" parts.
2. It's not reasonable to queue up an arbitrary amount of work without back-pressure.
I haven't used Tokio much, but if it falls prey to these pitfalls, it would make me pause before adopting it.
I think there are probably ways of using Rust async that don't fall prey to these. Maybe not so much with network servers (I haven't written that many of those), but models where you are evaluating a graph and have more control over how new work is added to the system.
Additionally, the proposed workload per thread model will be orders of magnitude slower than Tokio for I/O-bound workloads, which most applications are.
The punchline seems to be something like the LMAX disruptor style which is genuinely good for some things, but if you have I/O loops like the illustration shows you can easily block that loop with some long running function.. so you have the same cognitive load as managing thread pools or async pools or disruptors..
Or you are just trying to squeeze lemonade from stones, ala, they aren't meant to do what you are doing.
Tokio especially is extremely widely used for all kinds of things it doesn't work well for.
Sure I could improve it add or tune some primitives but I am honestly considering writing my own. And so should others.
I feel like we are all too bound in Rust ecosystem suddenly to Tokio and Rayon because we don't want to blame and acknowledge the libraries just don't work for what we want to use it for.
And library authors don't consider these usecases and bug important enough to actually fix it in a ergonomic way.
The first Web servers used CGI (Common Gateway Interface). This spawned an entire program (process) per request and had obvious overheads. This led to some optimizations (eg FastCGI, ISAPI/NSAPI) to reduce the overhead. This was the era of Perl scripts being popular.
Then came the model of having a persistent state across requests. Java servlets were a big example of this. Given the cost of exec'ing a process, this was a big deal. But then you've immediately created an environment where multiple threads were accessing the same resource and you could leak resources. There were other variants like CORBA.
Now this was abotu the time of the birth of PHP. PHP was revolutionary because it had a stateless core that allowed shared hosting environments, which were exceptionally cheap for the time (even though they had security issues). But the idea is that you avoided the threading issues of a persistent environment and didn't really have resource leaks because everything got torn down. Of course PHP had other issues. But this was a big deal because things like the initialization of a JVM class loader, for example, was relatively expensive and you had to tune Java servers around performance and STW GC pauses.
None of the above really has anything to do with programming languages other than people learned (or didn't learn) just how hard writing multithreaded code is, something that is true to this day and you absoultely want to avoid it if possible. It is incredibly difficult to get right in an era of cores, threads, different L1/L2 caches, out-of-order proccessing, branch prediction, etc etc etc. And your code may have to run on multiple architectures.
Now Go chose to get around this issue with goroutines and channels. I personally think these are a bad abstraction, particularly because buffered channels are used without understanding the impact (leading to deadlocks), you can have exploding goroutine sttacks and using unbuffered channels is a strictly inferior (IMHO) async/await abstraction.
I actually think that Facebook's Hack has basically the almost perfect async/await. The whole idea of async/await is that you get the benefits of the PHP model of being single-threaded in your own application code and you can tear down your environment when you're done. Any IO goes through async API functions.
Now how does the scheduler manage threads, exhaustion, etc in this environment? Honestly? I have no idea. It just basically works. So maybe the Tokio issue is that the scheduler itself is blocked, which seems to be the case from this article. That does seem like a flaw but a fixable one.
I get the whole colored function criticism but the reality of using Hack to serve HTTP requests is that everything is async anyway so it seems to be a non-issue in practice. You can if you really need to call call an async function from a non-async function with a blocking function but that's not best practice.
I do know that thread pools, particularly multiple thread pools, is not the answer.
Thread per request works perfectly fine if your application is CPU constrained.
However the observation was made, that most web applications are IO constrained, the majority of the time spent serving a web request is spent waiting for a database or downstream API.
Since most of the threads are idle waiting, your application needs many threads to optimally utilize the servers resources.
There was a perception(valid or not) that OS threads have too much memory and scheduling overhead.
Nginx came out using async io, and it could handle much more concurrent requests than apache, which used a threaded model, it sparked a lot of interest in different kinds of application managed scheduling.
It inspired initiatives like the reactive manifesto[0], which spawned tools like RXJava.
[0]: https://reactivemanifesto.org/
I'd draw the analogy to RPC; it's a leaky abstraction because HTTP is fundamentally a different thing than a function call. I'd argue that event loops are a different thing as well.
It's a bit like having a system composed of microservices (nanoservices?) that communicate via function calls.
It sounds a lot like the actor model, but I always found the classic architecture too limiting: requiring every actor to be a single-threaded message processor, instead of being able to handle requests concurrently. It's not too different from classic object-oriented design either, with singleton services.
In some project I've called my concurrent services Gods just to have a bit of fun with it :)
This is just because JS is single threaded. Python has the Global Interpreter Lock, which makes it effectively single threaded too. That means you don’t have to deal with true parallelism, and critical sections, semaphores etc. It’s like Ethereum: only one thing happens at a time.
But you don’t have to parse JSON without yielding. You can make anything async by just using setTimeout once in a while. Here is one such implementation: https://www.npmjs.com/package/yieldable-json
The guy may as well have said while(1) locks up Node.
Now they get into multithreaded work-stealing, and isolates. But the solution in Node is to spin up multiple processes and pass messages between them. This is approaching the Erlang actor model, and is also shared-nothing. They even say "the schedule is a single-threaded loop per core" and "all cross-core communication occurs via the messaging subsystem".
This can also be achieved in most other single-threaded languages, too. Python with asyncio, for instance.
Tina may provide a nice opinionated implementation with bounded queues and deterministic scheduling, but those are architectural choices rather than evidence that async/await itself has failed.
Node has isolates, but it's more for sandboxing.
(in case you missed it, authors mention them later and explain what they do: "Use Tokio for I/O, and send CPU-bound work to a dedicated thread pool like Rayon.")
Authors have whole section ("The Work-Stealing Myth") on Erlang.
Author's proposed solution ("Project Tina") is a new programming language written in Odin.
How on earth do you read this all and start talking about Javascript problems instead?