Read on Twitter
So, if this is now fixed, what's there to talk about?
Well, this is fixed in Go, but not in other languages/runtimes.
JS and Rust have the same issue Go used to have, but worse.
Well, this is fixed in Go, but not in other languages/runtimes.
JS and Rust have the same issue Go used to have, but worse.
They both use the "poor person" implementation of async calls: colored functions and "awaits".
This means that runtimes (e.g. the browser or tokio or what is trendy in Rust at the moment) can only schedule stuff on preemption points.
This means that runtimes (e.g. the browser or tokio or what is trendy in Rust at the moment) can only schedule stuff on preemption points.
And those preemption points are *not* automatically inserted: they only happen on async/await calls.
With this mechanism this issue *cannot* be fixed in Rust or JS. It's going to stay there forever.
With this mechanism this issue *cannot* be fixed in Rust or JS. It's going to stay there forever.
So to recap: Rust and JS have a cooperative scheduling mechanism that cannot be made preemptive and preemption points are *manually* added by programmers (so it's even worse than the state Go was in when I gave the talk).
Moreover the Go runtime more or less knows what it is scheduling, the Rust one does not (the JS one is... weird on this regard).
So this caused some very bad behaviors already to the point tokio (one of the most used Rust runtimes) had to implement some quite odd mechanisms
So this caused some very bad behaviors already to the point tokio (one of the most used Rust runtimes) had to implement some quite odd mechanisms
(Note that tokio implements a runtime that is very similar to the Go one: https://tokio.rs/blog/2019-10-scheduler)
They added *counters* https://tokio.rs/blog/2020-04-preemption
Basically to avoid some of the pathological behaviors they give functions budgets.
They added *counters* https://tokio.rs/blog/2020-04-preemption
Basically to avoid some of the pathological behaviors they give functions budgets.
If a function is keeping the runtime for themselves for too long they are forcefully scheduled away... but this can only happen if two circumstances are met:
1) Every single library you depend on uses the tokio (and only the tokio) socket, timer, channel, etc.
1) Every single library you depend on uses the tokio (and only the tokio) socket, timer, channel, etc.
2) A yielding point is reached.
Yes, because the issue here is not just that yielding points have to be manually added, they might also still not give a chance to the runtime to schedule smth else.
Yes, because the issue here is not just that yielding points have to be manually added, they might also still not give a chance to the runtime to schedule smth else.
"How bad can this possibly be?"
I guess time will tell, but let's just say that a good chunk of the Go runtime efforts went into fixing this issue *for two years*, so it's probably not smth people can just ignore.
I guess time will tell, but let's just say that a good chunk of the Go runtime efforts went into fixing this issue *for two years*, so it's probably not smth people can just ignore.
And this is without even considering the memory leak issues Rust has, but that's a story for another time.
