You can think of it as the reactor pattern. You only have one physical CPU so all you are doing is churning through callback-based event handlers.
The callbacks in this case might be the literal interrupt handlers (in which case your dispatcher "loop" is actually the hardware). Or else you make your interrupt write a little bit of state that then gets dispatched by your actual event loop.
Either way, you write responsive software by doing everything in short-running callbacks.
I find it amusing that (some) sophisticated GUI and server framework for big computers re-invent this.
One important difference is that in the MCU world interrupt handlers need to be really short and fast, because often various classes of interrupts are blocked from occurring while an interrupt handler is running. A common pattern is for the interrupt handler to just set some bits to say “this occurred” and return. The bits are then checked and handled in the main loop.
It's amusing how you and alexhutcheson both corrected me in opposite directions.
For reasons Alex explains, interrupt handlers have to be really minimal. So you often use them to set state that makes the main loop branch off into the "real" handler.
But even then, you often don't want to wait a long time in that handler either. That too becomes a short-running event handler (though not necessarily a callback). Just not as extremely short running as it would have to be if did it in the interrupt handler.
The callbacks in this case might be the literal interrupt handlers (in which case your dispatcher "loop" is actually the hardware). Or else you make your interrupt write a little bit of state that then gets dispatched by your actual event loop.
Either way, you write responsive software by doing everything in short-running callbacks.
I find it amusing that (some) sophisticated GUI and server framework for big computers re-invent this.