1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
//! 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.
pub use ;