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

[René J.V. Bertin]

KIdleTime really seems to have captured my attention - it's after all very closely related to "problems" I've had to solve more than a few times in a previous life.

Currently, the MS Windows and OS X backends have 2 issues with detecting & signalling idle timeouts, aside from the fact they allow a heavy margin of error:

- timeouts can be (and are) signalled early (by up to the detection margin). I tend to think that time delays should not never be reported early.
- timeouts can fail to be reported if detected too late.

For that 2nd point, consider an application that has a timeout set for 5s and that got swapped out, or that for some other reason detects too late that it has been idle for 5s. If this is detected at, say, 6.5s, there still has been 5s of idletime, but since the current idle time is outside the margin of error it is not signalled.

What does the XCB alarm-based mechanism do in this case? I would expect an alarm to fire even if it's late, rather than being missed completely.
Also, does the XCB implementation allow for early reporting of timeouts?

I'd test this empirically, but my current Linux systems aren't suitable for this kind of work.

R.