Interrupt Processors, not Processes

The title says it all. This is a note about OS or kernel design. Most systems support a concept of process which is embodied by a set of register values including a program counter and address space. When a processor is interrupted that processor redirects its attention to some other process but first putting down the register values for the old process and picking up those for the new. The old process is not interrupted, it is merely deferred, probably to be subsequently resumed.

Unix speaks of interrupting a process much as CPU hardware logic speaks of interrupting a processor. The engineering reason to interrupt a processor is that there is a limited number of processors and they must be allocated to tasks (processes) dynamically for reasons of salience, efficiency and promptness. This reallocation can not generally be anticipated by the logic of the program that occupies the processor when it comes time to switch tasks. None of these reasons for interrupting a processor apply to the process. The process is cheap. Where Unix practice would call for interrupting a process upon some event e, a better plan would be to have another different process waiting on e. This removes the whole concept of interrupt from the realm of the writer of user code. The only interrupt code is that of the kernel.