KIdleTime: early and/or failing/rejected timeout detection?

[René J. V. Bertin]

Martin Graesslin wrote:


> I don't really understand. How can it signal too early?

I was wrong about the MS Windows implementation, but from WidgetBasedPoller:

    Q_FOREACH(int timeOut, m_timeouts) {
        if ( ( timeOut - idle < 300 && timeOut >= idle ) || ( idle - timeOut < 
300 && idle > timeOut ) ) {
            // Bingo!
            emit timeoutReached( timeOut );
        }
    }

that code accepts any idle value that is within ±300ms of timeOut. Since idle 
increases monotonically after onset, and if comparisons are done often enough, 
the code will signal up to 300ms early.

> I can say for Wayland as I wrote that recently:

I'm guessing Wayland will provide a mechanism that's inspired by what Xcb 
provides?

> * it will fire if it's hit - there might be a delay which I think doesn't
> matter in the case of being swapped out.

Do you mean that the delay is independent of whether or not you're swapped out, 
or that the question of how long the delay is is moot if you are (were) swapped 
out? It will "Fire if it's hit", but what "it" doesn't get hit at the configured 
time but at a later time?

> The Wayland implementation doesn't give a guarantee that if there is an idle
> time of 5 sec it will be signalled exactly after 5 sec. That's something a
> non-realtime system cannot provide.

Of course not. But that doesn't mean it is pointless to try to minimise the 
delay (for instance by polling ;))
To put this into perspective: the last thing I wrote in this context was an 
extension to Matlab/Simulink that allowed to run a compiled Simulink model 
realtime on a sufficiently fast host, without need for special realtime 
hardware.
Let's be clear about this: true realtime indeed requires a special system, or at 
the very least support from the OS, and the appropriate coding approach in your 
own application. I have a hunch that Qt is already used "that way" (it exists on 
Qnx after all). There aren't that many applications that need 100%, "hard" 
realtime behaviour (as opposed to only a fraction of their running time). 
Realtime also isn't necessarily about the lowest possible delays (they just need 
to be known and more or less constant). OTOH there are many more types of 
applications that want to be perceived to run in real time, with the smallest 
possible delays. IMHO those kind of applications (games, simulators, 
psychophysics or other empirical software, ...) are much more likely to resort 
to convenience frameworks like those provided by KF5.
(I was going to add "apps for controlling little trains" but those probably have 
little need for KIdleTime, just for other time-related functions with comparable 
"good" behaviour :))

> And honestly I don't think it matters. KIdleTime is about being noticed about
> being idle. We are talking here about timeouts which are in an area where
> realtime doesn't matter [...]
> If you want
> to use KIdleTime for anything below let's say half a minute, I think it's the
> wrong tool for it.

And I really don't see the point in providing a framework for this (and 
basically only this) if it's not going to try to be as versatile as possible. It 
can and should aim to avoid hogging any resources in the default configuration. 
But as it happens it is actually more complicated to implement that than to 
implement the basic approach that can also provide the best precision and 
detection delays. I think the framework becomes more versatile if it allows 
users to switch it to a more precise/powerful and (possibly) more intrusive 
mode.
If of course the majority of major platforms on which it is deployed support the 
kind of precision I'm thinking of.

BTW, the exact durations are inconsequential (as long as they're above what can 
be timed a reasonable precision). It's not because you're interested to learn if 
an application has been idle for 10min that all of a sudden it becomes more 
acceptable to detect that with a much worse precision.

And FWIW: any backend that's based on QTimer and use Qt::PreciseTimer to achieve 
better than 5% error (= at least ms accuracy).

R.