External agents, such as devices and users, can always be represented by corresponding processes. Thus the issue is the extent to which one process can control another. As previously indicated, a process can restart a suspended subprocess, as well as terminate a subprocess. It can also be informed whenever a subprocess terminates itself or is suspended.
It may seen unreasonable to restrict the privilege of controlling a process to its parent process. However, restricting the privilege avoids the need to introduce an explicit ``right to control'' granting mechanism and makes it easier to check whether a process has the right to make a control request (especially in a distributed implementation of the operating system). Also, a programmer can synthesize control facilities in non-parent processes by letting the parent execute requests communicated to it by these processes. The restriction, therefore, simplifies the operating system without impairing functionality. Furthermore, the overhead of providing extended control rights is limited to those applications for which these are required.
An additional control feature often provided by operating systems is the ability to cause an interrupt or exception in another process. This can be achieved by allowing a process to suspend a subprocess, whereafter it can restart the subprocess at the address of the interrupt/exception handler. This allows, for example, a process to extricate a subprocess from an endless loop, and to restart it inside a ``cleanup and reset'' procedure.
Allowing a process to be suspended at an arbitrary point in its execution, and then to be restarted at another, causes some complications. Firstly, the ``interrupt'' handler entered when the suspended process is restarted may eventually wish to resume the interrupted control flow (in true interrupt handler fashion). Thus, when a process is suspended, the address of the instruction that was about to be executed must be saved on the process stack. Secondly, the interrupt handler may need to know the reason for the interrupt. Consequently, the parent must supply a reason code when it suspends a subprocess; this code is then stacked along with the ``return'' address. (When a subprocess suspends itself, it too supplies a reason code, and when it is suspended because of an error, the system provides a reason code.)
Suspending a subprocess so that it can be resumed cleanly from the point of interruption can be very difficult if the subprocess is inside a system call at the time that the suspension request is received (which can be at any time on most multi-processors). Consequently, a suspension request issued by a parent while the subprocess is inside a system call takes effect only when the system call returns. If the parent proceeds to restart a subprocess that is still waiting to be suspended, the completion of the parent's restart request is delayed until the subprocess can be suspended.
However, if a subprocess is inside a system call that may never return, for example when it is waiting for an input/output operation that will never be completed, then such a scheme will cause the parent to be delayed indefinitely when it tries to extricate its subprocess form an indefinite delay. Consequently, such system call must be interruptible.
When interrupted inside such calls, the stacked reason code is modified, and additional information is placed on the stack. An interrupt handler that wishes to return to the point of interruption can use this stacked information to resume the interrupted system call. On the other hand, an exception handler that must extricate the process form an erroneous control flow, rather than resume it, must be able to regard an interrupted system call as completed.
The complications that arise when a parent is allowed to suspend its subprocesses raise the question whether it is possible to dispense with this mechanism. However, the only alternative to suspending and restarting a run-away subprocess is to terminate it. When a process is terminated, all of its communication links are severed and all its subprocesses are terminated - otherwise, other complications would arise.
The cascading effects of terminating a process forming part of a set of co-operating processes may be too severe to be acceptable to a multi-process, real-time, fault-tolerant application. Albeit somewhat complicated, the semantics of suspend/restart seem preferable. And, even though complicated to describe, the suspend/restart mechanism can be implemented without exacting much overhead cost.
With regard to the automatic termination of subprocesses, note that a process can nevertheless create another subprocess that will survive itself. A process would do this by not creating the new process as its own subprocess, but by requesting an operating system provided non-terminating ``server'' process to create and control a subprocess on its behalf. Such a server would provide the functions of the background batch queues found in many operating systems.
