2

Reading about interrupts in linux, I understand that their handlers will run till completion (lets not consider the bottom halves here). So, assume that my code has SIGINT handler registered (using the signal()/sigaction() call) with a while(1)-loop in it (i.e the handler never returns).

If I quit my program abruptly while running, then shouldn't this scenario freeze my machine entirely? Won't my machine with only one CPU core go into an infinite loop?

What I mean is; since my interrupt handler is not returning, won't the CPU be stuck in executing the while(1) code only? (i.e no other process will get the chance of running, because there won't be any context-switch/preemption inside the handler or can the interrupt handler get preempted in between running the while(1) loop?)

quasarguru
  • 25
  • 5

1 Answers1

1

You definitely mix signal handlers and interrupt handlers, despite they have similar handling. Unlike you are writing kernel code you won't meet interrupt handlers directly.

But, game rules for signal handlers are very similar. You should either exit from a signal handler or finish the program (and, the latter is analog for stopping the whole system, for the kernel land). This includes exotic ways for exiting signal handlers as longjmp().

From kernel POV, a process in forever loop in an interrupt handler doesn't differ from a process with the same loop in a usual code piece like main(). Entering a signal handler modifies signal mask but doesn't change things radically. Such process can be stopped, traced, killed in the same manner as outside of signal.

(All this doesn't concern some special process classes with advanced credentials. E.g. X Window server can be special because it disables some kernel activity during its video adapter handling. But you likely should know the needed safety rules when writing such software.)

Netch
  • 4,171
  • 1
  • 19
  • 31
  • Thanks netch! That helped, gosh! I was totally in the wrong boat so far. So how is this thing exactly propagated right up to the user-space? When I press a Ctrl-C, no doubt an interrupt handler will be called in the kernel, but how is this attached to the relevant process context? the signal handler is called in the "relevant process context", right? as and when it will be scheduled. – quasarguru Dec 21 '13 at 14:15
  • By default, on pressing Ctrl+C all processes belong to the foreground process group of this terminal get SIGINT. This is done in a common terminal device discipline handler and can be disabled using termios configuration, or INT code can be changed. For further explanation google for "termios", and VINTR and ISIG inside its manuals. Then, the signal is delivered to processes using kernel-specific mechanism, which generally falls into putting it to pending signal set and waiting until process allows to call signal handler. – Netch Dec 21 '13 at 15:44