The Fork System Call
The Fork System Call
System call fork() is used to create processes. It takes no arguments and returns a process ID.
The purpose of fork() is to create a new process, which becomes the child process of the caller.
After a new child process is created, both processes will execute the next instruction following
the fork() system call. Therefore, we have to distinguish the parent from the child. This can be
done by testing the returned value of fork():
If fork() returns a negative value, the creation of a child process was unsuccessful.
fork() returns a positive value, the process ID of the child process, to the parent. The
returned process ID is of type pid_t defined in sys/types.h. Normally, the process ID is
an integer. Moreover, a process can use function getpid() to retrieve the process ID
assigned to this process.
Therefore, after the system call to fork(), a simple test can tell which process is the child. Please
note that Unix will make an exact copy of the parent's address space and give it to the
child. Therefore, the parent and child processes have separate address spaces.
Let us take an example to make the above points clear. This example does not distinguish parent
and the child processes. Click here to download this file fork-01.c.
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#define
#define
MAX_COUNT 200
BUF_SIZE 100
void main(void)
{
pid_t pid;
int i;
char buf[BUF_SIZE];
fork();
pid = getpid();
for (i = 1; i <= MAX_COUNT; i++) {
sprintf(buf, "This line is from pid %d, value = %d\n", pid, i);
write(1, buf, strlen(buf));
}
}
Suppose the above program executes up to the point of the call to fork() (marked in red color):
Page
1
make two identical copies of address spaces, one for the parent and the other for the child.
Both processes will start their execution at the next statement following the fork() call. In
this case, both processes will start their execution at the assignment statement as shown
below:
Both processes start their execution right after the system call fork(). Since both processes have
identical but separate address spaces, those variables initialized before the fork() call have the
same values in both address spaces. Since every process has its own address space, any
modifications will be independent of the others. In other words, if the parent changes the value of
its variable, the modification will only affect the variable in the parent process's address space.
Other address spaces created by fork() calls will not be affected even though they have identical
variable names.
2.
List the system calls used for process management:
Page
2
Environment variables
Environment variables are a set of dynamic named values that can affect the way
running processes will behave on a computer.
Or (from ignou c library )
When a program is executed, it receives information about the context in which it was invoked in
two ways. The first mechanism uses the argv and argc arguments to its main function, and is
discussed inProgram Arguments. The second mechanism uses environment variables and is
discussed in this section.
The argv mechanism is typically used to pass command-line arguments specific to the particular
program being invoked. The environment, on the other hand, keeps track of information that is
shared by many programs, changes infrequently, and that is less frequently used.
They can be said in some sense to create the operating environment in which a process runs. For
example, an environment variable with a standard name can store the location that a particular
computer system uses to store temporary filesthis may vary from one computer system to
another. A process which invokes the environment variable by (standard) name can be sure that it
is storing temporary information in a directory that exists and is expected to have sufficient space.
Working principles of environment variables
A few simple principles govern how environment variables BY INSTALLING, achieve their effect.
[edit]Local to process
Environment variables are local to the process in which they were set. That means if we open two
terminal windows (Two different processes running shell) and change value of environment
variable in one window, that change will not be seen by other window.
Page
3
[edit]Inheritance
When a child process is created, it inherits all the environment variables and their values from the
parent process. Usually, when a program calls another program, it first creates a child process
by forking, then the child adjusts the environment as needed and lastly the child replaces itself
with the program to be called. This procedure gives the calling program control over the
environment of the called program.
[edit]Case sensitive
In Unix and Unix-like systems the names of environment variables are case sensitive.
[edit]Persistence
Environment variables persistence can be session-wide or system-wide.
A parent and child can communicate through any of the normal interprocess communicationschemes (pipes, sockets, message queues, shared memory), but also
have some special ways to communicate that take advantage of their relationship as a parent
and child. One of the most obvious is that the parent can get the exit status of the child.
One of the most obvious is that the parent can get the exit status of
the child.
Since the child inherits file descriptors from its parent, the parent
can open both ends of a pipe, fork, then the parent close one end and
the child close the other end of the pipe. This is what happens when
you call the popen() routine to run another program from within
yours, i.e. you can write to the file descriptor returned from
popen() and the child process sees it as its stdin, or you can
read from the file descriptor and see what the program wrote to its
stdout. (The mode parameter to popen() defines which; if you want
to do both, then you can do the plumbing yourself without too much
difficulty.)
Also, the child process inherits memory segments mmapped anonymously (or
by mmapping the special file `/dev/zero') by the parent; these
shared memory segments are not accessible from unrelated processes.
what is a zombie process?
Page
4
On Unix and Unix-like computer operating systems, a zombie process or defunct process is
a process that has completed execution but still has an entry in the process table. This entry is
still needed to allow the parent process to read its child's exit status. The term zombie
process derives from the common definition of zombiean undead person. In the term's
metaphor, the child process has "died" but has not yet been "reaped". Also, unlike normal
processes, the kill command has no effect on a zombie process.
When a process ends, all of the memory and resources associated with it are deallocated so they
can be used by other processes. However, the process's entry in the process table remains. The
parent can read the child's exit status by executing the wait system call, at which stage the
zombie is removed. The wait call may be executed in sequential code, but it is commonly executed
in a handler for the SIGCHLD signal, which the parent receives whenever a child has died.
After the zombie is removed, its process ID and entry in the process table can then be reused.
However, if a parent fails to call wait, the zombie will be left in the process table. In some
situations this may be desirable, for example if the parent creates another child process it ensures
that it will not be allocated the same process ID. On modern UNIX-like systems (that comply
with SUSv3 specification in this respect), the following special case applies: if the
parent explicitly ignores SIGCHLD by setting its handler to SIG_IGN (rather than simply ignoring
the signal by default) or has the SA_NOCLDWAIT flag set, all child exit status information will be
discarded and no zombie processes will be left.
A zombie process is not the same as an orphan process. An orphan process is a process that is
still executing, but whose parent has died. They do not become zombie processes; instead, they
are adopted by init (process ID 1), which waits on its children.
Page
5
Zombie: process terminated, but information is still there in the process table.
Unix - What are the process states in Unix? - May 12, 2009 at 13:50 pm by Vidya Sagar
What are the process states in UNIX?
UNIX has the following process states:
1)
2)
3)
4)
Running
Suspended (sleep)
Stopped
Zombie
Allocate a slot in the process table, a list of currently running programs kept by UNIX.
iCopy the context of the parent, the process that requested the spawning of the new
process.
Return the new PID to the parent process. This enables the parent process to examine or
control the process directly.
Page
6
data for ls and then starts running that new program. The ls program is loaded into the new
process context, replacing the text and data of the shell. The ls program performs its task, listing
the contents of the current directory.
how do you execute one program from within another?
There are various ways to run another program from within your own. Most of the good ones are
compiler dependant, so best research your help files before going too far
In all the example code below you'll find some sample output. In the cases where a child program
has been invoked, this source was used to make that child:
#include <stdio.h>
int main(int argc, char *argv[] )
{
int i = 0;
printf("I am the child\n");
while (--argc)
printf ("Arg %d %s\n", ++i, *++argv);
return 0;
}
Page
7
Unix identifies each process with a unique integer called ProcessID. The process that executes
the request for creation of a process is called the 'parent process' whose PID is 'Parent Process
ID'. Every process is associated with a particular user called the 'owner' who has privileges
over the process. The identification for the user is 'UserID'. Owner is the user who executes the
process. Process also has 'Effective User ID' which determines the access privileges for
accessing resources like files.
getpid() -process id
getppid() -parent process id
getuid() -user id
geteuid() -effective user id
Page
8