At this point i'm not concerned about anything, my intention is to experiment with this approach. The promise is to balance work more evenly across all available cpu-cores, depending on how the kernel alternates accept calls between workers. This should then result in effectively handling more clients on the same machine.
Edit: According to the next quote, my expectation is wrong; it's possible to handle more clients at the same time. This is NOT the same as handling more clients in total. This leads to the possibility of handling more clients under specific circumstances.
There will be minimal blocking, mostly because of logging and limited shared state access.
Database reads/writes, which will block, are 'offloaded' to other threads to simulate async. I have actually no idea about the impact of additional threads for blocking database operations.
Correct, it's a post incident approach to rebalancing.
Actor state is required to be Send + 'static while using Tokio::runtime (reactor thread + threadpool executor). Changing the underlying runtime into the described approach would not require changes to the upper implementation, i suspect.
I also remembered this post from Tokio, mentioning that moving the entire event loop to an other thread is often cheaper (i suppose lower latency). This is somewhat into the direction of what i'm trying to achieve, but it moves all other tasks onto another thread instead of redistributing them over the other workers. It's also backwards in the sense that a blocking operation explicitly executes this behaviour instead of allowing the other workers to share in the load.
It peeked my interest anyway and decided to do a deep dive into the Tokio -executor, -reactor and -threadpool crates, to find out how this (it all) works in detail. The deep dive was inevitable, now that i think about it..
I think i can cook up something soon.
Thanks for the replies!