time.sleep() under Windows

[Tim Peters]

[Tim, on Ctrl+C interrupting time.sleep() in 2.3 on Win2K]
> ...
> It was also enabled on Win9x, but I tested that and it caused
> system (OS) instability there.  We're never going to know why, so the
> ability to interrupt sleep() on Win9x was ripped out again.

[Alex K. Angelopoulos]
> Just a guess, since I don't know Python well enough to trace back
> the underlying API calls, but the underlying system time calls on
> Win9x go back to an actual BIOS Get Clock call of some kind - that's
> one of the reasons that the resolution of most simple timer functions
> on Win9x systems are limited to about 55 milliseconds.  I wouldn't
> be surprised if it is never available to anything else after the
> break. NT/2000/XP appear to do something completely different which
> emulates the call.

That would have been a good explanation had I been telling the truth.  But
turns out I was lying:  there was no problem letting Ctrl+C interrupt
time.sleep() under any flavor of Windows, and 2.3 supports it.

What *was* ripped out on Win9x was the also-new ability to let Ctrl+C
interrupt processes created by the os.popen() family.  In 2.2 and before,
CREATE_NEW_CONSOLE was always passed (on Windows) to CreateProcess(), and
that stopped Ctrl+C in the original console window from being seen in
spawned children.  On Win2K Mark (Hammond) was able to get away with not
passing CREATE_NEW_CONSOLE, but on Win9x not passing CREATE_NEW_CONSOLE
sporadically caused "mystery error boxes" to pop up, from somewhere in the
bowels of the Win9x virtual memory system, complaining about internal
resource conflicts and warning that the system had likely become unstable
(which it often was then).  Spawning processes is a nightmare on Win9x, and
no bug in that area has ever been tracked to a fully satisfactory
conclusion.  At this point, "get a real OS" is the Company Line.