Protecting against callbacks queuing up?
Hendrik van Rooyen
hendrik at microcorp.co.za
Fri Aug 28 10:52:01 CEST 2009
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:
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:
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):
you do not need this separate.
just do this:
calculate what must be calculated
> 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
if, in that routine, you go:
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 :)
More information about the Python-list