Async-based task framework.
The well-known tokio runtime is general async runtime, and it is good. In fact, we are using tokio as a component of the task framework. Howver, shear tokio is not well-suited for a UI applications:
First of all, we want to prioritize UI rendering and response to user interactions, this means we shouldn't treat all tasks in the application equally. However, tokio views all tasks equally, there's no difference between a task in respond to user interaction and a task performing massive computation.
What's worse, a UI application usually has a UI thread running an UI event poll, which is the place triggering rendering and interaction logic. Meantime, tokio is a work-stealing async runtime, which might steal the massive computation work to the UI thread if we are running tokio on the UI thread.
Actually, separating thread is not enough, there's case when the UI thread and tokio thread running massive task are scheduled on the same CPU, which might also downgrade the performance of UI thread as it relies on timer interrupt to reclaim the CPU. We will also want to set the CPU affinities whenever it's possible.
This is why the task framework comes in. We provides facilities for configuring thread model for UI applications, as well as specifying type of work, and spawning them on the correct threads.