I was reading the thread about the difference in cpu-core saturation between Tokio and Actix implementations of a webserver here.
@vitalyd came with the following explanation.
A rough resume is that Actix’ workers each accept clients on the same bound address. Eventually this results in better distribution of work across cores at the cost of higher avg/max latency. Detailed explanation here, which was linked by @parasyte .
As i read that article i figured work-stealing might help reduce max latency for requests on blocked workers. Is this possible to build on top of current Tokio components?
At first i figured manually starting new threads with a current_thread reactor and -executor. Lacking only the work stealing component between these threads.
Tokio itself has a threadpool executor which implements work stealing, but it’s behaviour is not a perfect match. It’s desired that each reactor should always assign tasks to the same thread, not a random thread within an attached pool.
According to the Tokio runtime docs an executor instance also runs on top of a reactor. Given I use the existing threadpool implementation, this concept turns upside down. The intention, after all, would be to run a separate reactor for each thread in the pool.
So to make my question (see above) more concrete; Can the Tokio threadpool component be used underneath the Tokio reactor somehow?
Is this a correct approach? Am i overcomplicating this, because the desired functionality can actually be implemented using (most of) the current Tokio modules?