Render timing.c robust in the face of strangeness. The strangenesses
authorsimon <simon@cda61777-01e9-0310-a592-d414129be87e>
Mon, 28 Mar 2005 17:48:24 +0000 (17:48 +0000)
committersimon <simon@cda61777-01e9-0310-a592-d414129be87e>
Mon, 28 Mar 2005 17:48:24 +0000 (17:48 +0000)
commit2ac3322ef9bc032ad942753a56696764aa0b0f74
treec4a1690bfa7d59cf77c5e3a140482e40a456a2a1
parent939c2b22a74142b76a62ba02b9da29ccb20dc5c2
Render timing.c robust in the face of strangeness. The strangenesses
in question vary per OS: on Windows the problem is that WM_TIMER
sometimes goes off too early, so that GetTickCount() is right and
the callback time is wrong, whereas on Unix the problem is that my
GETTICKCOUNT implementation comes from the system clock which means
it can change suddenly and non-monotonically if the sysadmin is
messing about (meaning that the timing of callbacks from GTK or
select timeouts is _more_ likely to be right than GETTICKCOUNT).
This checkin provides band-aid workarounds for both problems, which
aren't pretty but ought to at least prevent catastrophic assertion
failure.

git-svn-id: svn://svn.tartarus.org/sgt/putty@5556 cda61777-01e9-0310-a592-d414129be87e
timing.c
unix/unix.h
unix/uxmisc.c
unix/uxplink.c
unix/uxsftp.c
windows/winstuff.h