can interrupt handlers be interrupted by other interrupt handlers

[suppie]

what i learnt is that interrupt handlers dont run in process context and cannot be preempted.

whan an interrupt handler is called, the interrupts on the current irq is disabled. if SA_INTERRUPT is not set, other irqs are still active.

i want to know what happens if another irq y is interrupted when one irq x is being serviced.

is the current isr x preempted to run isr y ? or the new isr y is called only after the current isr x returns ?

[Rubberman]

These are very complex issues and cannot really be given due dilligence in a forum like this. The short answer is that yes, some interrupts can be interrupted by other interrupts (gag - what a sentence!). However, there are non-preemptable interrupts that MUST run to completion of their handler code. When a pre-emptable interrupt is running, and another interrupt occurs that is a higher priority interrupt, then they will "nest", in current parlance. The code for all of this is buried deep in the most fundamental part of the kernel. In any case, how long an interrupt routine runs will demonstrably impact the performance of a system, and can cause lost interrupts, or in the case of real-time systems the missing of a hard deadline. For this, and other reasons, interrupt handlers should be kept as short and simple as possible, generally only setting some flag that other code can detect and then process appropriately. For example, in a serial device interrupt handler, the handler will only check to see if there is data available to read or write, set appropriate flag variables, and then return to the kernel. The driver will then detect this and do the appropriate thing of either reading the data from the device, or writing waiting data to the device.

So, in the case of your question, if the interrupt handler for irq x is running and an irq y interrupt occurs, the handler for y will behave thusly:

1. If y is higher priority than x, it will pre-empt x's handler, returning to x's handler when done.
2. If x is higher priority than y, it will keep running and y's handler will be called when x's is done.
3. If x is non-preemptable, then it will always run to completion, no matter what other interrupts occur.
4. If x and y interrupts happen simultaneously, then their priority order is observed. If of the same priority, then it depends upon the OS whether they are run in irq order, or randomized.

Anyway, this is some of the "rocket science" of operating system engineering.

[suppie]

omg that was an awesome explaination. thanks a lot rubberman.

[Rubberman]

Remember, not all operating systems behave the same way. It depends upon their implementation. There used to be a good paper on the QNX web site about their implementation and the behavior of interrupts on their hard real-time operating system. You might find it on QNX Realtime Operating System (RTOS) software, middleware, development tools and services for superior embedded design if you are interested. FYI, the RIM Blackberry tablet that is coming out soon will be run on QNX since RIM bought the company recently.