Executing periodic actions [duplicate]

At the end of foo(), create a Timer which calls foo() itself after 10 seconds.
Because, Timer create a new thread to call foo().
You can do other stuff without being blocked.

import time, threadingdef foo():    print(time.ctime())    threading.Timer(10, foo).start()foo()#output:#Thu Dec 22 14:46:08 2011#Thu Dec 22 14:46:18 2011#Thu Dec 22 14:46:28 2011#Thu Dec 22 14:46:38 2011

Simply sleeping for 10 seconds or using threading.Timer(10,foo) will result in start time drift. (You may not care about this, or it may be a significant source of problems depending on your exact situation.) There can be two causes for this - inaccuracies in the wake up time of your thread or execution time for your function.

You can see some results at the end of this post, but first an example of how to fix it. You need to track when your function should next be called as opposed to when it actually got called and account for the difference.

Here's a version that drifts slightly:

import datetime, threadingdef foo():    print datetime.datetime.now()    threading.Timer(1, foo).start()foo()

Its output looks like this:

2013-08-12 13:05:36.4835802013-08-12 13:05:37.4849312013-08-12 13:05:38.4855052013-08-12 13:05:39.4869452013-08-12 13:05:40.4883862013-08-12 13:05:41.4898192013-08-12 13:05:42.4912022013-08-12 13:05:43.4924862013-08-12 13:05:44.4938652013-08-12 13:05:45.4949872013-08-12 13:05:46.4964792013-08-12 13:05:47.4978242013-08-12 13:05:48.4992862013-08-12 13:05:49.500232

You can see that the sub-second count is constantly increasing and thus, the start time is "drifting".

This is code that correctly accounts for drift:

import datetime, threading, timenext_call = time.time()def foo():  global next_call  print datetime.datetime.now()  next_call = next_call+1  threading.Timer( next_call - time.time(), foo ).start()foo()

Its output looks like this:

2013-08-12 13:21:45.2925652013-08-12 13:21:47.2930002013-08-12 13:21:48.2939392013-08-12 13:21:49.2933272013-08-12 13:21:50.2938832013-08-12 13:21:51.2930702013-08-12 13:21:52.293393

Here you can see that there is no longer any increase in the sub-second times.

If your events are occurring really frequently you may want to run the timer in a single thread, rather than starting a new thread for each event. While accounting for drift this would look like:

import datetime, threading, timedef foo():    next_call = time.time()    while True:        print datetime.datetime.now()        next_call = next_call+1;        time.sleep(next_call - time.time())timerThread = threading.Thread(target=foo)timerThread.start()

However your application will not exit normally, you'll need to kill the timer thread. If you want to exit normally when your application is done, without manually killing the thread, you should use

timerThread = threading.Thread(target=foo)timerThread.daemon = TruetimerThread.start()

Surprised to not find a solution using a generator for timing. I just designed this one for my own purposes.

This solution: single threaded, no object instantiation each period, uses generator for times, rock solid on timing down to precision of the time module (unlike several of the solutions I've tried from stack exchange).

Note: for Python 2.x, replace next(g) below with g.next().

import timedef do_every(period,f,*args):    def g_tick():        t = time.time()        while True:            t += period            yield max(t - time.time(),0)    g = g_tick()    while True:        time.sleep(next(g))        f(*args)def hello(s):    print('hello {} ({:.4f})'.format(s,time.time()))    time.sleep(.3)do_every(1,hello,'foo')

Results in, for example:

hello foo (1421705487.5811)hello foo (1421705488.5811)hello foo (1421705489.5809)hello foo (1421705490.5830)hello foo (1421705491.5803)hello foo (1421705492.5808)hello foo (1421705493.5811)hello foo (1421705494.5811)hello foo (1421705495.5810)hello foo (1421705496.5811)hello foo (1421705497.5810)hello foo (1421705498.5810)hello foo (1421705499.5809)hello foo (1421705500.5811)hello foo (1421705501.5811)hello foo (1421705502.5811)hello foo (1421705503.5810)

Note that this example includes a simulation of the cpu doing something else for .3 seconds each period. If you changed it to be random each time it wouldn't matter. The max in the yield line serves to protect sleep from negative numbers in case the function being called takes longer than the period specified. In that case it would execute immediately and make up the lost time in the timing of the next execution.