How does the kernel cope with the schedule() function being called from within an IRQ? Say, task1 calls schedule from IRQ0 (timer), and task2 resumes from INT 80h (I forget the name of the system call that forces a task switch). The IRQ “ACK” signal would never be sent, and IRQs would cease to be sent.
I am referring to x86 PCs only. I am researching the Linux scheduler/process system for my own small kernel I am (attempting) to write, and I can’t get my head around what I’m missing. I know I’m missing something since the fact that Slackware is running on my computer is a testament to the fact that the scheduler works 😛
The short answer is that it doesn’t. On normal Linux systems, ISR context is considered an atomic context meaning that you should not yield control to the scheduler at any point. In case some code does call schedule() from an interrupt context, you would most likely get a “BUG: scheduling while atomic” print.
However, it is possible to re-schedule the process following the end of the interrupt handling and that’s what the time interrupt occasionally does in order to divide the CPU resource among processes. Also, some patched Linux kernels have delegated the work of ISRs to kernel threads, and in that case those special ISRs might sleep.