Protecting against callbacks queuing up?

[Esben von Buchwald]

Hendrik van Rooyen wrote:
> 
> Hmm - now I am really starting to fly by the seat of my pants - but it looks 
> as if your problem is that your routine is basically being called faster than 
> what it can do the processing.
> 
> So what I would try is to define a global (you should really acquire a lock, 
> but forget that for the moment) So lets call this thing running_calculation.
> 
> Then you set this in the routine just before the after call, and reset it just 
> before exiting the calculation routine, and if it is set when you get into 
> the first routine, then you just exit, without doing the after.   This should 
> have the effect of skipping some calls, to make it all manageable.  Then you 
> should (hopefully) not have the duplication that it looks to me like you are 
> now having.
> 
> Bye the way, make the time short - like 1 - it could also be that the time is 
> now so long before you start calculating, that you do not have a snowball's 
> hope in hell to be finished before the next value comes in.
> 

OK, now things starts to make sense.

You tell me to do something like this?


     def doCallback(self):
         if self.process_busy==False:
             self.process_busy=True
             self.at.after(0.01,self.data_callback)
     def doneCallback(self):
             self.process_busy=False


And the after command will cause python to spawn a new thread, which 
runs self.data_callback, which measn that the doCallback will return 
immediately, so the next callback from accelerometer can be processed?

And when the self.data_callback() finishes, i'd make it call the 
doneCallback() to release my busy flag, right?

I'm gonna try this tomorrow :)