Dennis, > So... you need to adjust for the time spent in processing between > calls to sleep().
That was my first thought too, but any code calculating that adjustment before ultimatily calling sleep itself can also be interrupted. With that in mind I was aiming/hoping for something with a /very/ short path between the calculation and executing the sleep (as in: none at all, done by the system itself). > The creep could be mitigated some by having the handler's first > action being to start the next timer instance, and then doing "stuff". Yup. But the cost of using that command is generating threads - which some search results warned against (not sure why though). The best solution I can think of would be a build-in (hardware?) timer which would generate "ticks" until its stopped. Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
