When does OS check signals?

For simplicity,let's suppose it's on a single core architecture.

OS' main responsibility is to assign CPU time to different processes.

When does it check signals?

My bet is that it checks it when switching context(hang p开发者_StackOverflow社区roc A and wait B) ,but I don't have any proof..

The answer, sadly, depends on the OS. On most, if not all, OS signals are event-driven entities. For example, in the case of a hardware interrupt, the hardware sends the signal to the interrupt handler, which then does its stuff, usually upon a context-switch (like you suggested).

It depends on the OS exactly, but in the case of a signal sent from a specific program, it usually happens when you context-switch a process to be executed. Signals are then checked. In the case of kill, the kill command is "tied" to the process, and the OS' interrupt handler takes care of it.

Operating systems have interrupt handlers that deal with that kind of thing. They periodically check, but it realy depends on the OS. In the specific case of kill PID (I use this example because you used it in an above comment), it will check the next time PID is scheduled for continued execution.

Short but unsatisfying answer: it depends on the signal and on the OS.

Hope this helps! N.S.

Sources: I've programmed operating systems before, and I've taken multiple concurrency classes.

It doesn't poll for them if that's what you mean. When someone asks the kernel to send a signal, it interrupts the program to handle it.

Segfaults are triggered by hardware interrupts. The interrupt handler asks the kernel to pass the message along. Timeouts are similar.

It's all event-driven. Although some of the events quickly and simply leave messages around to be collected later for later - mouse movements etc. What happens next is very system-dependent but it's not a signal anymore.