System Interface Guide

Chapter 2 Processes

This chapter describes processes and the library functions that operate on them.


Executing a command starts a process that is numbered and tracked by the operating system. Processes are always generated by other processes. For example, log in to your system running a shell, then use an editor such as vi(1). Take the option of invoking the shell from vi(1). Execute ps(1) and you see a display resembling this (which shows the results of ps -f):

abc24210 1006:13:14tty290:05-sh
abc2463124210006:59:07tty290:13vi c2
abc28441283588009:17:22tty290:01ps -f
abc2835824631209:15:14tty290:01sh -i

User abc has four processes active. The process ID (PID) and parent process ID (PPID) columns show that the shell that started when user abc logged on is process 24210; its parent is the initialization process (process ID 1). Process 24210 is the parent of process 24631, and so on.

A program might need to run one or more other programs based on conditions it encounters. Reasons that you might not want to create one large executable include:

The fork(2) and exec(2) functions let you create a new process (a copy of the creating process) and start a new executable in place of the running one.


The functions listed in Table 2-1are used to control user processes:

Table 2-1 Process Functions

Function Name 



Create a new process 








Execute a program 



Terminate a process 


Wait for a child process to stop or terminate 


Translate address to symbolic information 


Close a shared object 


Get diagnostic information 


Open a shared object 


Get the address of a symbol in a shared object 



Set user and group IDs 


Set process group ID 



Change working directory 


Change root directory 


Change priority of a process 



Get and set current user context 



Get or set supplementary group access list IDs 





Get process, process group, and parent process IDs 





Get real user, effective user, real group, and effective group IDs 


Suspend process until signal 


Control process scheduler  


Set process group ID 


Set session ID 


Wait for a child process to change state 

Spawning New Processes


fork(2) creates a new process that is an exact copy of the calling process. The new process is the child process; the old process is the parent process. The child gets a new, unique process ID. fork(2) returns a 0 to the child process and the child's process ID to the parent. The returned value is how a forked program determines whether it is the parent process or the child process.

The new process created by fork(2) or exec(2) function inherits all open file descriptors from the parent including the three standard files: stdin, stdout, and stderr. When the parent has buffered output that should appear before output from the child, the buffers must be flushed before the fork(2).

The following code is an example of a call to fork(2) and the subsequent actions:

	pid_t		pid;

 	pid = fork();
 	switch (pid) {
 		case -1:			/* fork failed */
 			perror ("fork");
 			exit (1);
 		case 0:			/* in new child process */
 			printf ("In child, my pid is: %d\n", getpid(); );
 			exit (0);
 		default:			/* in parent, pid contains PID of child */
 			printf ("In parent, my pid is %d, my child is %d\n", getpid(), pid);

 	/* Parent process code */

If the parent and the child process both read input from a stream, whatever is read by one process is lost to the other. So, once something has been delivered from the input buffer to a process, the buffer pointer has moved on.

Note -

An obsolete practice is to use fork(2) and exec(2) to start another executable, then wait for the new process to die. In effect, a second process is created to perform a subroutine call. It is much more efficient to use dlopen(3DL), dlsym(3DL), and dlclose(3DL) as described in "Runtime Linking" to make a subroutine temporarily resident in memory.


exec(2) is the name of a family of functions that includes execl(2), execv(2), execle(2), execve(2), execlp(2), and execvp(2). All load a new process over the calling process, but with different ways of pulling together and presenting the arguments of the function. For example, execl(2) could be used like this

	execl("/usr/bin/prog2", "prog2", progarg1, progarg2, (char (*)0));

The execl argument list is:


The path name of the new program file 


The name the new process gets in its argv[0]

progarg1, progarg2

The arguments to prog2 as char (*)s

(char (*)0)

A null char pointer to mark the end of the arguments 

There is no return from a successful execution of any variation of exec(2); the new process overlays the process that calls exec(2). The new process also takes over the process ID and other attributes of the old process. If a call to exec(2) fails, control is returned to the calling program with a return value of -1. You can check errno to learn why it failed.

Runtime Linking

An application can extend its address space during execution by binding to additional shared objects. There are several advantages in this delayed binding of shared objects:

Process Scheduling

The UNIX system scheduler determines when processes run. It maintains process priorities based on configuration parameters, process behavior, and user requests. It uses these priorities to assign processes to the CPU.

Scheduler functions give users varying degrees of control over the order in which certain processes run and the amount of time each process can use the CPU before another process gets a chance.

By default, the scheduler uses a time-sharing policy. A time-sharing policy adjusts process priorities dynamically in an attempt to give good response time to interactive processes and good throughput to CPU-intensive processes.

The scheduler also provides an alternate real-time scheduling policy. Real-time scheduling allows users to set fixed priorities--priorities that the system does not change. The highest priority real-time user process always gets the CPU as soon as it can be run, even if other system processes are also eligible to be run. A program can therefore specify the exact order in which processes run. You can also write a program so that its real-time processes have a guaranteed response time from the system.

For most versions of SunOS 5.0 through 5.8, the default scheduler configuration works well and no real-time processes are needed: administrators need not change configuration parameters and users need not change scheduler properties of their processes. However, for some programs with strict timing constraints, real-time processes are the only way to guarantee that the timing requirements are met.

For more information, see priocntl(1), priocntl(2), and dispadmin(1M). For a fuller discussion of this subject, see Chapter 3, Process Scheduler .

Error Handling

Functions that do not conclude successfully almost always return a value of -1 to your program. (For a few functions in man Pages(2): System Calls, there are calls for which no return value is defined, but these are the exceptions.) In addition to the -1 that is returned to the program, the unsuccessful function places an integer in an externally declared variable, errno. In a C program, you can determine the value in errno if your program contains the following statement:

#include <errno.h>

The value in errno is not cleared on successful calls, so check it only if the function returns -1. Since some functions return -1 but do not set errno refer to the man page for the function to be sure that errno contains a valid value. See error descriptions in Intro(2).

Use the C language function perror(3C) to print an error message on stderr based on the value of errno, or strerror(3C) to obtain the corresponding printable string.