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
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
//! The platform's own exemption from the way it slows a process whose window is not
//! visible.
//!
//! The service dispatches every 100 ms for its whole life, and both platforms this product
//! runs on have a treatment aimed exactly at a process in that situation: macOS naps an
//! application and coalesces its timers once its windows are not visible and it is not
//! audible, and Windows drops the Quality of Service of a window owner that is occluded or
//! minimised and not audible, far enough to ignore the timer-resolution requests it makes.
//! Both platforms document a per-process exemption from that treatment, and asking for it is
//! all this module does — once per start, on the daemon's own start-up path, so it holds for
//! the whole life of the service instead of being tied to a window, to a user action or to
//! one operation. Desktop Linux has no such treatment for a process of our kind, so nothing
//! is asked there and nothing is reported.
//!
//! What is deliberately *not* asked for is any scheduling privilege: this process's own
//! priority is left alone, no real-time class is requested, and nothing machine-wide is
//! changed. That last one rules out Windows' battery-only downgrade of a foreground
//! application after a period without user input: it exists only as a value in the machine's
//! registry and would apply to every application on the machine, so it is left alone rather
//! than switched off, and the request below claims nothing about it.
//!
//! The boundary with the machine's own sleep, decided once and applied on every platform:
//! [`exempt_from_slowdown`] does not keep the display on, does not keep the machine from
//! entering its own low-power state at the normal time, and adds no keep-awake assertion of
//! any kind — the macOS option set is the arm of the activity family that leaves the
//! sleep-disabling bit out (`OPTIONS`). Voice input and read-aloud take no part in this:
//! they do not run through this module, and nothing here adds or removes a keep-awake of
//! theirs. A platform that instead suspends desktop applications once the display turns off
//! (modern standby) takes the service with the machine: that is accepted, and it is not
//! something this request may change.
//!
//! Accepted trade-off, deliberate and without an escape hatch: with the exemption in force
//! the service keeps its full cadence while its window is hidden, minimised or behind
//! others, which costs power and heat, and no setting, environment variable or command-line
//! flag turns it off.
//!
//! The request names one process and is made once, on the service's start-up path, so no
//! spawn site makes a second one. A child of the service owns no window of its own: where
//! the platform classifies such a child by the window its ancestor owns rather than by
//! anything the child declares (Windows assigns a descendant of a window-owning process its
//! Quality of Service from that window), the child is part of the service's own situation and
//! is not a third party the platform treats on its own — which is the whole reason the single
//! request above is the only one made. Only a third-party tool the service runs — a shell, a
//! compiler, a browser, which the platform classifies for itself — is out of scope, and this
//! request says nothing about it.
//!
//! Nothing here is fatal: a platform that refuses, ignores or does not support the request
//! leaves the launch exactly as it would have been without it. What came back is stated by
//! the start-up line (`main.rs`) rather than kept quiet, so the exemption is reported as a
//! request — accepted, refused, or not supported on this platform or build — and never as
//! protection.
use ;
/// What the platform answered when the exemption was asked for.
/// The one request a start-up makes and what came back, for the start-up status line.
/// The activity macOS is asked for, and the whole of the sleep boundary on this platform:
/// `UserInitiatedAllowingIdleSystemSleep` is the activity the platform's App Nap guide names
/// for work that must not be deferred, and it is the arm of the family whose mask leaves the
/// sleep-disabling bit out; `LatencyCritical` is the platform's only *process-wide* lever on
/// the other half of the treatment — "the highest amount of timer and I/O precision
/// available", the flag it documents for latency-sensitive work — and is what this request
/// carries against timer coalescing. The per-timer levers (`DISPATCH_TIMER_STRICT`, the
/// kqueue note flags) cover one timer each and cannot carry a service whose whole cadence has
/// to survive. The two together are `NSActivityUserInteractive` with the idle-sleep bit
/// removed; the assertion below pins that, and measures it the only way the platform allows —
/// on macOS 26.5 a process holding this option set is absent from `pmset -g assertions` for
/// the whole time it holds it, while one holding `NSActivityUserInitiated` or
/// `NSActivityUserInteractive`, whose masks carry that bit, is listed there as
/// `PreventUserIdleSystemSleep`.
///
/// The other effect this carries, held for the life of the service rather than for the short
/// burst the platform documents `LatencyCritical` for, is exactly that above-baseline timer
/// and I/O precision: accepted deliberately, because the platform warns against holding such
/// an activity for an extended period and offers nothing narrower, and a request that left
/// the precision half in force would not turn the treatment off completely.
const OPTIONS: NSActivityOptions = UserInitiatedAllowingIdleSystemSleep
.union;
// The one slip that would pass every other check while quietly keeping the machine awake for
// good is an option family that also disables idle sleep, so the mask is pinned at compile
// time, where the mask is.
const _: = ;
/// Ask macOS not to nap this application and not to coalesce its timers.
///
/// Holding the returned object *is* the exemption: the platform ends the activity the moment
/// it is deallocated, so the token is deliberately leaked for the life of the process (which
/// is what ends it). A dropped token would silently put the service back under App Nap.
///
/// The termination bits that ride inside every `UserInitiated`-family mask are counted here
/// as well and are inert for this product: sudden and automatic termination are opt-ins
/// through a bundle's Info.plist (`NSSupportsSuddenTermination` /
/// `NSSupportsAutomaticTermination`), and the service is a bare binary with no bundle. The
/// product's own exit routes are unaffected (see `shutdown`, which owns that list).
///
/// The token is the platform's whole answer and is never null by contract, so a refusal
/// cannot be observed here and none is invented; whether the activity really keeps App Nap
/// off is not readable from inside the process either, the platform stating outright that
/// user preferences may override the request. So the start-up line reports the request, and
/// the effect is read from the platform's own records instead — this process's App Nap state,
/// and the machine's sleep-assertion list for the boundary above.
/// Ask Windows for High Quality of Service, with both of its throttling mechanisms off.
///
/// The whole mechanism set goes into a single call: `ControlMask` declares the mechanisms
/// this process controls and `StateMask` which of them are on, so a second call would leave
/// the process controlling only what the second one names. The platform's own examples ask
/// for its two mechanisms separately; this deliberately does not.
///
/// A Windows 10 build — which the x86_64 product still supports — does not know the
/// timer-resolution flag and rejects the whole request over it, so the execution-speed
/// mechanism is asked for on its own instead, and that narrower request is what gets
/// reported. Nothing of the treatment is left in force by the fallback: the mechanism the
/// flag turns off is a Windows 11 behaviour such a build does not have.
///
/// The declaration stands for the life of the service, so the platform's window-state
/// heuristics no longer classify this process — not by its window's visibility, not by its
/// audibility. What the call left behind is readable back where the build supports it
/// (`GetProcessInformation` with the same class), which is what a check reads. Accepted
/// deliberately: keeping the dispatch cadence is the point of the request, and the platform
/// documents nothing narrower that turns the mechanisms off.