[Python-ideas] time.Timer

Terry Reedy tjreedy at udel.edu
Wed Feb 26 19:21:54 CET 2014


On 2/26/2014 12:37 PM, anatoly techtonik wrote:
> On Wed, Feb 26, 2014 at 11:29 AM, Chris Angelico <rosuav at gmail.com> wrote:

>> For measuring FPS,
>> you should probably use an algorithm more like this:
>>
>> 1) Spawn an FPS counter thread, or async alarm, or something, to be
>> executed every second.

> I don't want to mess with woes of concurrent programming
> for this kind of accuracy. Python is good at what it is good for.

What 'Python is good at' changes when new features and modules are 
added. The new asynch module is about 'non-blocking' programming. Its 
sleep task makes having a process periodically wake up, do something, 
and go back to sleep simple. We may assume that async.sleep(n) uses 
whatever non-blocking watchdog timer system call is available in the 
major OSes. There is not much reason left to program one in Python.

> https://stackoverflow.com/questions/134867/which-programming-language-makes-concurrent-programming-as-easy-as-possible

The first answer is to use a functional language because values are 
never changed. For this use, the FPS reporter should access an 
'anti-functional' changing counter. Of course, the 'counter' is not 
actually changed (as it would be if it were a named memory slot in C). 
Rather than name 'counter' is rebound to another int. In any case, there 
worry is that is two threads or threadlets rebind the name, one or the 
other will get discombobulated. That is not the case here.

>> 2) Each frame, increment a counter. Never reset the counter.
>
> Although offtopic, but I don't get why resetting a counter is worse
> than storing two values and subtracting them.

Since the frame function that increments the counter does not care if it 
is reset to 0, I might have the FPS reported reset it. Either way is a 
minor detail.

-- 
Terry Jan Reedy



More information about the Python-ideas mailing list