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
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
//! How much processor time this server has used, for `INFO cpu`.
//!
//! It is one `getrusage` call and it is here rather than in a platform crate
//! because `INFO` is the only thing that asks. A monitoring tool graphs this
//! against wall clock to see whether a server is busy or waiting, so a made up
//! zero would be worse than nothing: a flat line reads as an idle server.
//!
//! Redis reports six numbers and this reports four. The two that are missing
//! are `used_cpu_sys_main_thread` and `used_cpu_user_main_thread`, which need
//! `RUSAGE_THREAD`, and that is Linux only. Reporting the process totals under
//! a name that says main thread would be right on a single threaded server and
//! wrong on the one this becomes, so they are left out.
//!
//! Windows has no `getrusage` and it does have `GetProcessTimes`, which is the
//! same two numbers for this process. What it has no equivalent of is the child
//! totals, so those two are zero there and that is true rather than made up:
//! this server starts no children.
//!
//! On a platform with neither there is no `# CPU` section at all, and a client
//! that does not find the field falls back, where a client that finds a zero
//! believes it.
/// Processor time used since this process started, in seconds.
///
/// The first pair is this process and the second is every child it has waited
/// for, which is the split Redis reports.
/// Read the counters, or `None` where the platform has no way to.
/// The user and system totals for one `RUSAGE_` target, in seconds.
///
/// A failed call is zero rather than a refusal, because the only documented
/// failure is an argument that is not one of the constants and both of the ones
/// passed here are.
/// The same, under an interpreter that has no process to account for.
///
/// Miri shims no `getrusage` on any target, so the real one above ends the run
/// rather than answering, and it is not one test that walks into that: `INFO`
/// with no argument prints every section, so most of the dispatch tests do.
///
/// Zero here is the same answer the call above gives when the kernel refuses,
/// which is a reading the rest of the code already takes, and it is the true
/// one as far as anything can tell: what Miri is spending is the host's time
/// interpreting, not this process's time running. Nothing is monitoring an
/// interpreter, and the tests that care about the numbers moving say so and
/// are left out of the Miri run.
/// Read the counters, or `None` where the platform has no way to.
///
/// `GetProcessTimes` is the Windows equivalent of `getrusage` for this process
/// and it is exact rather than sampled. There is no equivalent for children:
/// Windows does not keep a running total for processes this one has waited for,
/// because it has no `wait` in that sense and no parent child accounting to hang
/// one off. This server starts no children, so the honest total for them is
/// zero, and that is what those two fields say.
/// A `FILETIME` as seconds.
///
/// It is a count of hundred nanosecond ticks split across two 32 bit halves,
/// and it is not aligned well enough to be read as a `u64` in place, which is
/// why Windows hands it over in halves in the first place.
/// Read the counters, or `None` where the platform has no way to.