Process Creation

Process Creation

Operating systems require some way to make processes. In very simple systems, or in systems designed for running only a single application  (e.g., the controller in a microwave oven), it may be possible to have all the processes that will ever be needed be present when the system  comes up. In general-purpose systems, however, some way is required to create and finish processes as required during operation. We will now look at some of the issues.

There are four principal events that cause processes to be created:

1 . System initialization.

2. Execution of a process creation system call by a running process.

3 . A user request to create a new process.

4 . Initiation of a batch job.

When an operating system is booted, normally various processes are created. Some of these are foreground processes, that is, processes that interact with (human) users and perform work for them. Others are background processes, which are not associated with specific users, but instead have some particular function. For instance, one background process may be designed to accept incoming e-mail, sleeping most of the day but suddenly springing to life when incoming e-mail arrives. Another background process may be designed to accept incoming requests for Web pages hosted on that machine, waking up when a request arrives to service the request. Processes that stay in the background to handle some activity such as e-mail, Web pages, news, printing, and so on are called daemons. Large systems generally have dozens of them. In UNIX, the ps program can be used to list the running processes. In Windows, the task manager can be used.

In addition to the processes created at boot time, new processes can be created afterward as well. Often a running process will issue system calls to create one or more new processes to help it do its job. Creating new processes is mostly useful when the work to be done can easily be formulated in terms of various related, but otherwise independent interacting processes. For instance, if a large amount of data is being  fetched over a network for subsequent processing, it may be suitable to create one process to fetch the data and put them in a shared buffer while a second process removes the data items and processes them. On a multiprocessor, allowing each process to run on a different CPU may  also make the job go faster.

In interactive systems, users can start a program by typing a command or (double) clicking an icon. Taking either of these actions starts a new process and runs the selected program in it. In command-based UNIX systems running X, the new process takes over the window in which it was started. In Microsoft Windows, when a process is started it does not have a window, but it can create one (or more) and most do. In both systems, users may have multiple windows open at once, each running some process. Using the mouse, the user can select a window and interact with the process, for instance, providing input when required.

The last situation in which processes are made applies only to the batch systems found on large mainframes. Here users can submit batch jobs to the system (possibly remotely). When the operating system decides that it has the resources to run another job, it creates a new process and runs the next job from the input queue in it.

In principle, in all these cases, a new process is created by having an existing process execute a process creation system call. That process may be a running user process, a system process invoked from the keyboard or mouse, or a batch manager process. What that process does is carry out a system call to create the new process. This system call tells the operating system to create a new process and indicates, directly or indirectly, which program to run in it.

In UNIX, there is only one system call to create a new process: fork. This call creates an exact clone of the calling process. After the fork, the two processes, the parent and the child, have the same memory image, the same environment strings, and the same open files. That is all there is.  Generally, the child process then executes execve or a similar system call to change its memory image and run a new program. For instance, when a user types a command, say, sort, to the shell, the shell forks off a child process and the child executes sort. The reason for this two-step process is to allow the child to handle its file descriptors after the fork but before the execve in order to complete redirection of standard input, standard output, and standard error.

In Windows, on the contrary, a single Win32 function call, CreateProcess, handles both process creation and loading the correct program into the new process. This call has 10 parameters, which contain the program to be executed, the command- line parameters to feed that program, several security attributes, bits that control whether open files are inherited, priority information, a specification of the window to be created for the process  (if any), and a pointer to a structure in which information about the newly created process is returned to the caller. In addition to CreateProcess,  Win32 has about 100 other functions for managing and synchronizing processes and related topics.

In both UNIX and Windows, after a process is created, the parent and child have their own separate address spaces. If either process changes a word in its address space, the change is not visible to the other process. In UNIX, the child's initial address space is a copy of the parent's, but  there are certainly two separate address spaces involved; no writable memory is shared (some UNIX implementations share the program text  between the two since that cannot be modified). It is, however, possible for a newly created process to share some of its creator's other resources, such as open files. In Windows, the parent's and child's address spaces are different from the start.


system calls, batch system, memory