This approach does not waste processor resources for polling and provides a very short reaction time since interrupt processing is performed at the hardware level. However, developers should be aware of its specifics to avoid critical or hard-to-detect issues in the future.
First of all, dealing with multiple interrupts at the same time, or responding to the same interrupt while still handling the previous interrupt, is hard to implement. That is why ISRs are executed with interrupts disabled. This prevents the ISR from being interrupted with another interrupt, but it also means that the reaction time for the pending interrupt can be longer. Worse, this can lead to data or events being lost if interrupts are not re-enabled quickly.
To avoid such situations, all ISRs are written to be short. They only do a minimal amount of work to read or acknowledge...
