Gabriele Monaco <[email protected]> writes: > On Tue, 2026-05-19 at 09:49 +0200, Nam Cao wrote: >> CLOCK_REALTIME is the only clock that often is misused in real-time >> applications. The other clocks either are safe for real-time uses >> (CLOCK_TAI, CLOCK_MONOTONIC, CLOCK_BOOTTIME) or are unlikely to be misused >> (CLOCK_AUX, CLOCK_PROCESS_CPUTIME_ID). >> >> The rtapp monitor's purpose is warning people about common mistakes with >> real-time design. However, warning about all clock types generates too much >> false positives. > > I'm fine with the change, but are those really false positives? > > From what I understand before this change we would report any non-rt-friendly > clock type, now only realtime. > What we are skipping would still be true positives, just so uncommon not to > justify the extra complexity, right? > > Or do you mean an RT task using CLOCK_AUX is a false positive because likely > the > users weren't even trying to do real-time?
CLOCK_BOOTTIME is fine for RT. CLOCK_AUX is created for real-time use cases, so the monitor shouldn't warn about it. But this clock can also be arbitrarily set, which can be unsafe (e.g. you want to deploy the air bag in 10us, but someone changes the clock and you have to wait 10s). We probably can detect if a clock used by an RT task is set, but I am not sure how complicated that is, if even possible. For now we are assuming that user won't do such thing, then CLOCK_AUX is fine for RT uses. CLOCK_PROCESS_CPUTIME_ID is a strange one and shouldn't be used for real-time. But I think it's obvious from the description that you cannot do real-time with that. Only CLOCK_REALTIME is a mistake people often make, probably has something to do with the deceptive name. Nam
