1. Using Processes

2. The fork System Call Revisited
While fork is called one, it returns twice
If successful, it will return a value of 0 to the child process
If failed, it will return a –1 and set the global variable, errno
After the fork system cal, both the parent and child processes are running and continue their execution at the next statement after the fork

3. The fork System Call Revisited (continue)
To view how to generate a child process, click here
The output sequence is dependent upon the scheduling algorithm used by the kernel
To view Multiple activities parent/child processes, click here
$ a.out
PARENT
CHILD $

4. exec’s Minions
It is important to remember that when a process issues any exec call, if the call is successful, the existing process is overlaid with a new set of program code
The text, data and stack segment of the process are replaced and only the u (user) area of the process remains the same
The new program code begins its execution at the function main
Some things, by necessity, must change
Signals that were specified as being caught by the process are reset to their default action, as the address for the signal catching routines are no longer valid

5. exec’s Minions (continue.)
If the process was profiling (determining how much time is spent in individual routines), the profiling will be turned off in the overlaid process
If the new program has its SUID bit set, the effective EUID and EGID are set accordingly
If successful, the exec calls do not return as the calling image is lost
In a programming environment, the exec system calls can be used to execute another program

6. exec’s Minions (continue.)
The prototypes for the exec system calls, listed in their entirely, are:

7. exec system call functionality
Library Call Name
Argument Format
Pass Current Environment Variables?
Search of PATH Automatic
execl
list
yes no
execv
array
execle
execve
execlp
execvp

8. exclp system call Include File(s) <unistd.h> Summary
int execlp( const char *file,
const char *arg0, …,
const char *argun,
char * /*NULL*/ );
Return
Success
Failure
Sets errno
Does not return -1
Yes

9. exec’s Minions (continue.)
For the execlp call to be successful, the file referenced must be found and be marked as executable
If the number of arguments for the program to be executed is dynamic, then the system call execvp
To view how to use execlp system call, click here
% a.out test.txt
This is a sample text file for a program to display! %

10. excvp system call Include File(s) <unistd.h> Summary
int execvp( const char *file,
const char *arg[ ]);
Return
Success
Failure
Sets errno
Does not return -1
Yes

11. exec’s Minions (continue.)
To view how to use execvp with argv values, click here
% a.out cat test.txt
This is a sample text file for a program to display!
% a.out cat -n test.txt
1 This is a sample text file for a program to display! %

12. exec’s Minions (continue.)
If argv values of the current program are not used with execvp, then the programmer must construct a new argv to be passed.
An example of how this can be done is shown in the following
To view how to use execvp with a programmer-generated argument, click here

13. Using fork and exec’s together
The parent process generates a child process which it then overlays by a call to exec
To view how to use fork with execlp, click here
$ a.out
Fie
Foh
Fum $

14. Using fork and exec’s together (continue)
Shell program that restricts the user to a few basic commands (ls, ps and df)
To view the huh? Shell, click here

15. Ending a Process (continue.)
A process normally terminates in one of three ways
In order of preferences, this are:
It issues (at any point in its code) a call to either exit or _exit
It issues a return in the function main
It falls off the end of the function main ending implicitly

16. exit system call Include File(s) <stdlib.h> Summary
void exit(int status);
Return
Success
Failure
Sets errno
no return
No return

17. Ending a Process (continue.)
The exit function accepts a single parameter, and integer status value, that will be returned to the parent process
The header file <stdlib.h> contains two defined constants, EXIT_SUCCESS and EXIT_FAILURE, which can be used to indicate program success and failure respectively

18. Ending a Process (continue.)
Upon invocation, the exit function performs three actions:
exit( )
atexit Function
Registered?
_cleanup( )
_exit( )
Execute the
Function
yes no

19. Ending a Process (continue.)
The definition of atexit indicates that functions to be called (when the process terminates normally) are registered by passing the atexit function the address of the function
The registered function should not have any parameters
If the atexit is successful in registering the function, atexit will return a 0, otherwise, it returns a non-zero value

20. atexit system call Include File(s) <stdlib.h> Summary
int atexit(void (*func) (void));
Return
Success
Failure
Sets errno
No-zero
Yes

21. Ending a Process (continue.)
To view how to use atexit library function, click here
When run, the output of the programs shows that the registered functions are called in inverse order
$ a.out
Getting ready to exit
Doing F3
Doing F2
Doing F1 $

22. Ending a Process (continue.)
Programmers may call _exit directly, if they wish to circumvent the invocation of atexit registered functions and _cleanup

23. _exit system call Include File(s) <stdlib.h> Summary
void _exit(int status);
Return
Success
Failure
Sets errno
Does not return

24. Ending a Process (continue.)
When terminating a process, the system performs a number of housekeeping operations:
All open file descriptors are flushed and closed
The parent of the process is notified (via a SIGCHILD signal) that the process is terminating)
Status information is returned to the parent process (if it is waiting for it). If the parent process is not waiting, the system stores the status information until a wait process is affected
All child processes of the terminating process have their parent ID (PPID) set to 1 the process ID of init

25. Ending a Process (continue.)
Shared memory segments and semaphore references are readjusted
If the process was running accounting, the accounting record is written out to the accounting file

26. Waiting on Processes
A parent process needs to synchronize its actions by waiting until a child process has either stopped or terminated its actions

27. wait system call Include File(s) <sys/types.h>
<sys/wait.h>
Summary
pid_t wait(int *stat_loc);
Return
Success
Failure
Sets errno
Child PID -1
Yes

28. Waiting on Processes (continue.)
Child process
present?
Wait for Child
Process Terminated?
Return Status Value
and Child PID
Returns –1 and
Set errno no
yes no
Block
yes

29. Waiting on Processes (continue.)
When a waited-for child process terminates, the status information for the child and its process ID (PID) are returned to the parent
The status information is stored as an integer value at the location referenced by the pointer, stat_loc
The low-order 16 bits of the location contain the actual information, and the high-order bits are set to zero
The low-order bit information can be further subdivided into low- and high-order byte. This information is interpreted in one of two ways:

30. Waiting on Processes (continue.)
If the child process terminated normally, the low-order byte will be ) and the high_order byte will contain the exit code (0-255):
If the child process terminated due to an uncaught signal, the low-order byte will contain the signal number and the high-order byte will be 0:
Byte 3
Byte 2
Byte 1
Byte 0
Exit code
Byte 3
Byte 2
Byte 1
Byte 0
signal #

31. Waiting on Processes (continue.)
If a core file has been produced the leftmost bit of byte 0 will be a 1
If a NULL argument is specified for wait, the child status information is not returned to the parent process, the parent is only notified of the child’s termination
To view how to use wait, click here for parent process and here for child process

32. Waiting on Processes (continue.)
$ a.out
Forked child 3556
Forked child 3557
Forked child 3559
Wait on PID: 3559 returns status of : 0000
Forked child 3558
Forked child 3560
Wait on PID: 3557 returns status of : 0000
Wait on PID: 3560 returns status of : 0000
Forked child 3562
Wait on PID: 3562 returns status of : 0000
Forked child 3561
Wait on PID: 3558 returns status of : 0000
Wait on PID: 3556 returns status of : 0000
Wait on PID: 3561 returns status of : 0000

33. Waiting on Processes (continue.)
$ a.out
Forked child 3564
Forked child 3565
Forked child 3566
Forked child 3567
Wait on PID: 3567 returns status of : 0000
Forked child 3568
Wait on PID: 3565 returns status of : 0000
Wait on PID: 3568 returns status of : 0000
Forked child 3570
Wait on PID: 3570 returns status of : 0000
Forked child 3569
Wait on PID: 3566 returns status of : 0000
Wait on PID: 3564 returns status of : 0000
Wait on PID: 3569 returns status of : 0000

34. References INTERPROCES COMMUNICATIONS IN UNIX BY J. GRAY
UNIX SYSTEM PROGRAMMING BY K.HAVILAND, D. GRAY AND B. SALAMA