process operation

Process Operation -- Starting, controlling, and ending a process or procedure.

1. process creation-

A process operates in a cycle consisting of the following steps:
1.
the process is awakened by one of the awaited events
2.
the process responds to the event, i.e., executes a fragment of its code method
3.
the process puts itself to sleep
Before a process puts itself to sleep, it usually issues at least one wait request--to specify the event(s) that will wake it up in the future. A process may also issue a persistent wait request (see section 3.3.2), to be restarted cyclically by the subsequent occurrences of the same event. A process that goes to sleep without specifying a single waking condition is terminated. There is no sense to keep such a process around, as it will never run again. The effect is exactly the same as if the process performed delete on its object handle as its last statement (section 3.2).
To put itself to sleep, a process (its code method) can execute the following statement: sleep
or simply return from the code method.
The following operation handles wait requests:
wait ai event state priority
Only the first two arguments are mandatory. The first of them identifies the agent (the so-called activity interpreter (AI for short) responsible for triggering the waking event; the second argument specifies the actual event.
Activity interpreters are discussed in section 4. We saw one of them, the timer, in the example in section 3.2. In that case, the event was the delay in milliseconds after which the timer was expected to go off.
Argument state is optional and defaults to an empty string. It specifies the state to be assumed when the awaited event wakes up the process. This state will be returned in the process attribute State which can be examined by the code method.

2.process termination-

Process termination
Processes terminate in one of two ways:

Normal Termination occurs by a return from main or when requested by an explicit call to exit or _exit.
Abnormal Termination occurs as the default action of a signal or when requested by abort.
On receiving a signal, a process looks for a signal-handling function. Failure to find a signal-handling function forces the process to call exit, and therefore to terminate. The functions _exit, exit and abort terminate a process with the same effects except that abort makes available to wait or waitpid the status of a process terminated by the signal SIGABRT (see exit(2) and abort(3C)).
As a process terminates, it can set an eight-bit exit status code available to its parent. Usually, this code indicates success (zero) or failure (non-zero), but it can be used in any manner the user wishes. If a signal terminated the process, the system first tries to dump an image of core, then modifies the exit code to indicate which signal terminated the process and whether core was dumped. This is provided that the signal is one that produces a core dump (see signal(5)). Next, all signals are set to be ignored, and resources owned by the process are released, including open files and the working directory. The terminating process is now a ``zombie'' process, with only its process-table entry remaining; and that is unavailable for use until the process has finally terminated. Next, the process-table is searched for any child or zombie processes belonging to the terminating process. Those children are then adopted by init by changing their parent process ID to 1). This is necessary since there must be a parent to record the death of the child. The last actions of exit are to record the accounting information and exit code for the terminated process in the zombie process-table entry and to send the parent the death-of-child signal, SIGCHLD (see ``Signals, job control and pipes'').
If the parent wants to wait until a child terminates before continuing execution, the parent can call wait, which causes the parent to sleep until a child zombie is found (meaning the child terminated). When the child terminates, the death-of-child signal is sent to the parent although the parent ignores this signal. (Ignore is the default disposition. Applications that fork children and need to know the return status should set this signal to other than ignore.) The search for child zombies continues until the terminated child is found; at which time, the child's exit status and accounting information is reported to the parent (remember the call to exit in the child put this information in the child's process-table entry) and the zombie process-table entry is freed. Now the parent can wake up and continue executing.