Raspberry Pi Forums

While using the GPIO callback feature , is it possible to interrupt a running callback when another GPIO is triggered.

The function I am looking for is as follows:

A GPIO pin is set high and Callback 1 is triggered which is to play a video.
Now another GPIO pin is set high and therefore Callback 1 (which is have not yet completed playing the video) is abruptly stopped and CallBack 2 is executed , which plays a different video.


Would this be possible?

How are you going to stop the original playing video? When you know how to do that then just place that code in the second callback.

joan wrote:How are you going to stop the original playing video? When you know how to do that then just place that code in the second callback.

I do have a couple of callback functions (12 to be precise) . All of them play the video just fine when a GPIO pin is triggered. The problem is that while a callback function is being executed , I am unable to stop it in the middle and start a different callback function by triggering another GPIO pin.

I have to wait till the callback function is completed before I trigger another one. I find it strange cause it happens even though the main thread (which still runs kind of parallel with the callback function) is constantly checking for new GPIO triggers.

To summarise:

1)if Main thread plays a video , i can interrupt that to run a callback video
2)but when callback is running a video , i am unable to interrupt it to run a different callback video .

So was wondering if interrupting a running callback was possible

I understand.

It's best not to launch long running jobs actually in a callback as typically callbacks (as usually implemented) will all run in the same thread.

Set a flag "please play video" in the callback and have the main loop check for the flag and actually play the video.

joan wrote:I understand.

It's best not to launch long running jobs actually in a callback as typically callbacks (as usually implemented) will all run in the same thread.

Set a flag "please play video" in the callback and have the main loop check for the flag and actually play the video.

I think that might work , gonna try that and fingers crossed it works. thanks a lot for putting it in layman's terms joan . Appreciate it!

joan wrote:typically callbacks (as usually implemented) will all run in the same thread.

even pigpio callbacks work in this way?

I believe so. There may be a separate thread per Pi. You should certainly treat a callback as an old fashioned ISR and do as little processing as possible in as fast as possible a time.

joan wrote:I believe so.

Can't see the reason of that. Maybe to preserve the order of callbacks?

pattagghiu wrote:

joan wrote:I believe so.

Can't see the reason of that. Maybe to preserve the order of callbacks?

Practicality really. Say you have 80 edges from a DHT22, you'd end up creating 80 threads to handle those callbacks. Python wouldn't have time to be doing anything other than creating and destroying threads.

But, as you say, sometimes it is important to preserve event order, it is useful to know you will receive gpio events in the order they happened.

joan wrote:Practicality really. Say you have 80 edges from a DHT22, you'd end up creating 80 threads to handle those callbacks. Python wouldn't have time to be doing anything other than creating and destroying threads.
But, as you say, sometimes it is important to preserve event order, it is useful to know you will receive gpio events in the order they happened.

So the "correct" way when some "math" is needed is to use callbacks only to "store" data, and then use the core thread (or another thread manually created) to do calculations.
This makes sense.

Thanks for the info

joan wrote:I understand.

It's best not to launch long running jobs actually in a callback as typically callbacks (as usually implemented) will all run in the same thread.
.

Hypothetically If callbacks had run on different threads , do you think it would have been possible to interrupt them in the middle.
As far as I can understand right now , you cannot interrupt a thread in the middle by calling the same thread again. Is that right?

jacks909 wrote:Hypothetically If callbacks had run on different threads , do you think it would have been possible to interrupt them in the middle.
As far as I can understand right now , you cannot interrupt a thread in the middle by calling the same thread again. Is that right?

Well, you can interrupt it if you use a variable that is common through threads.
When a thread changes the variable, the other thread can see it, so you can check it to know when kill the thread..

jacks909 wrote:

joan wrote:I understand.

It's best not to launch long running jobs actually in a callback as typically callbacks (as usually implemented) will all run in the same thread.

Set a flag "please play video" in the callback and have the main loop check for the flag and actually play the video.

Just to confirm , what joan suggested works !! Thanks a lot!

Morale of this discussion : Treat GPIO callbacks similar to traditional Interrupt Service Routines , keep them short and sweet