Wout

Looking at the code, it can be 99% be resolved by a small modification to run_py_callbacks(unsigned int gpio) by moving the code inside the if (cb->gpio == gpio) branch outside the loop, this would allow the callback to modify the callback linked list without crashing the loop. This would leave still a tiny chance of the callback getting called during the initial setup of the callbacks, getting into a race condition if I'm right, but I haven't looked at how the threading is set up yet. So a lock...

I've made the modifications to allow callbacks adding/removing callbacks, see attached files. I've moved performing the call backs to outside the loop, so the callback doesn't mess up the loop. Plus I've added a mutex so another thread cannot mess up the loop if the other thread is adding/removing callbacks. There's only one tiny risk during startup, since the polling thread is created/started when adding the first callback, in theory when that callback is called right away, it can add callbacks,...

Make adding and removing event handlers (add_event_detect and remove_event_detect) thread safe.