a software can somehow prevent the servicable periodicity of that clock-updating routine by very small amounts,...resulting in a system clock that's a bit behind.... the time is read from the CMOS clock and everything's fine again... A game could (look at some Windows games).

This situation did manifest itself with some games under Windows'95/98 (maybe ME, though I found no references to that), but they are 16-bit, essentially DOS-based, with little or no distinction between user-mode and kernel-mode code.

On anything later than that (NT/2K/2K3/XP etc.), this is only likely to occur via a badly written device driver that uses something like a CriticalSection to prevent the kernel from responding to interrupts. It is conceivable that some extreme games/graphics cards might do this, deliberately sacrificing clock accuracy to gain a little redraw performance at very high resolutions, but it should be rare, and probably documented.

It is also possible that device drivers for specialist hardware (laboratory or very high speed communications, equipment) might also deliberately make this trade, but again, you would probably be aware of the possibility, if you had such devices and drivers.

It is unlikely, maybe impossible, that anything written to run exclusively in user-mode, like perl and POE could have such an effect.

So unless you are intending this to run under 95/98, on a system that games are frequently played, or will have non-standard hardware and device drivers, you're probably safe from this particular problem.