Protecting against callbacks queuing up?

[Hendrik van Rooyen]

On Friday 28 August 2009 00:42:16 Esben von Buchwald wrote:

> 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)

This bit is allmost right - try to make the time a millisecond or less, if you 
can. (however that is specified - I do not know) The spelling is probably:

        self.at.after(1,self.data_callback, (other_stuff))

where "other stuff" comes from the event and is what is needed to do the 
calculation. - the event should be an argument to the doCallback thinghy too, 
somehow, so that you can get at what you need to do the calculation.

>      def doneCallback(self):
>              self.process_busy=False
>
you do not need this separate.
just do this:

def data_callback(self,other_stuff):
    calculate what must be calculated
    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?

Yes and skipped if the calculation is not done yet.  Obviously you will have 
to do whatever it takes to make sure the events keep coming (if anything), so 
it may end up a little more complex, but you basically have the idea now.

The thing that happens as a result of the after is not really a new thread, it 
is a piece of the main loop that gets diverted for a while to do the 
calculation.

if, in that routine, you go:

while True:
    pass

You will completely freeze up the whole bang shoot..

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

see above - just clear it from the called routine.

>
> I'm gonna try this tomorrow :)

Good luck!

- Hendrik