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

[Martin Graesslin]

On Tuesday, November 17, 2015 2:59:57 PM CET René J.V. Bertin wrote:
> 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.

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

> 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 can say for Wayland as I wrote that recently:
* it cannot fire too early
* 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.

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.

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 and also being swapped out 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.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151117/237706b4/attachment.sig>