While looking into a solution for the post GPIO event detect not giving output when button pressed I found a couple of other posts on the subject of call backs in python for the Raspberry Pi.
- Python RaspberryPi GPIO Event Detection in Tkinter Failing
- Raspberry Pi RPi.GPIO error with threated callback
These posts made me wonder what is the underlying implementation used in python for handling a call back and what are the limitations of this implementation?
A post on the Raspberry Pi forum (see https://www.raspberrypi.org/forums/viewtopic.php?t=128510 ) indicated that there is a single thread, label it the call back thread, which is used for processing all call backs so should there be multiple events triggering a call back, there is a kind of queue and the call back thread removes call back requests from the queue and processes each within the call back thread and not the main thread or any other thread. This implies that should a call back perform some kind of a lengthy calculation then any other call backs waiting to be processed will be delayed.
However there is no link to documentation in the post and the post is from 2015 so perhaps that was python2.
One of the above StackOverflow posts, Raspberry Pi RPi.GPIO error with threated callback , describes a problem with using os.system()
in a call back function and when the os.system()
function is called in the main script rather than the call back function, it works fine.
So what is the implementation of the call back functionality in python2 and python3? What are some of the limitations for a call back function e.g.:
- minimize calculations and time taken as much as possible
- minimize functions called and nesting depth
- minimize local variables used and the size of those variables