4.0b3: timeout handling

[Tim Waugh]

On Wed, Sep 03, 2003 at 06:45:43PM +0100, Tristan Richardson wrote:

> I don't see how the original code could go wrong even if time went
> backwards, unless there's some combination of signed/unsigned 32/64-bit
> time_t/int that produces a weird value.  It would cause a timeout if time
> went sufficiently far forwards, but then arguably that would be the correct
> behaviour anyway. I'd be interested to know if your change seems to make any
> difference.

Now that I look more closely, I can see that I was mistaken.  Well
perhaps what happened was that time went forward by a lot.  The
specific instance in which it was reproducible was on one particular
machine during an automated installation of Red Hat Linux, with the
installer screen running over VNC.

It's quite probable that the machine in question had its clock wrong
and it got corrected during install I think.

So yes, there is no need to change the idle timeout handling.

> The deferUpdate timer just uses the X server's standard timer
> mechanism.  That's harder to modify since it's in the X server code
> and would need yet another patch which always introduces the fun
> possibility of it failing on different X trees....:-)

The deferUpdate timer fault seems a lot harder to trigger.  I've only
seen it myself twice, and I've had a separate report of it from
someone else.

Which I knew how to trigger it.

Tim.
*/

[demime 0.99d.1 removed an attachment of type application/pgp-signature]