Protecting against callbacks queuing up?

MRAB python at
Fri Aug 28 01:05:37 CEST 2009

MRAB wrote:
> Esben von Buchwald wrote:
>> Dennis Lee Bieber wrote:
>>>     The only other thing I could suggest is exactly what is done on:
>>>     Initialize a counter value to 0, then increment it in the callback,
>>> only doing REAL work every n calls.
>>>     def doCallback(self):
>>>         if self.count % 35 == 0:    #doc says 35 hits/second, so this
>>>             self.data_callback()    #will run one once per second
>>>         self.count += 1
>>>     You'll still get that slew of backlogged callbacks that built up
>>> while doing the real processing, but unless self.data_callback() takes
>>> more time than the "35" covers, most of the callbacks will just come in
>>> and exit with an increment.
>> Of course I can do that.
>> But it'll only make a noticable delay EVERY time the user moves, and 
>> not prevent the build up of calls if it doesn't finish within the 35 
>> callbacks.
>> The point is that I don't know in advance, how long the call will 
>> take. It depends on the amount of data i load and process during the 
>> call.
>> I only know when the calculations have finished, and when they are 
>> called, and think there might be some way to block further callbacks 
>> until the first one returns?
> You could record when your callback finishes (is about to return) and
> then ignore any callback that happens too soon after that:
>     def doCallback(self):
>         now = time.time()
>         if now - self.last_call >= MIN_TIME:
>             self.data_callback()
>             now = time.time()
>         self.last_call = now

After a little more thought, I think that should be:

     def doCallback(self):
         if time.time() - self.last_call >= MIN_TIME:
             self.last_call = time.time()

More information about the Python-list mailing list