1. OS – Process Creation and Destruction
CS/COE 0449 (term 2174)
Jarrett Billingsley

2. Class announcements We can talk about project 2 now :D
If that’s even on your mind, still.
About project 3…
gdb is still your friend ;D
Stop avoiding using thoth. You have to use it.
Don’t copy and paste.
Don’t do it.
Really.
Stop.
Use functions and variables.
Oh yeah, exam on Thursday I guesssssssss……………
3/14/2017
CS/COE term 2174

3. POSIX Process Creation
3/14/2017
CS/COE term 2174

4. Mitosis Code Memory Code Memory fork() In the beginning…
When a UNIX/Linux system first starts, the only process running is init.
If you do pstree, it’s the root!
The way every process starts in POSIX is by splitting off from another process.
The POSIX API function is called fork().
The original process is the parent, and the newly-forked process is the child.
Just like when cells split, both processes are completely identical!
Same code, same data, same everything.
Even where it’s executing is the same…
Parent
Child
Code
Memory
Code
Memory
fork()
3/14/2017
CS/COE term 2174

5. fork() is weird. Parent Child int cpid = fork(); if(cpid == 0) {
Let’s look at an example of fork().
We can use strace -f to watch the syscalls from both processes.
When you do a fork()…
Parent
Child
int cpid = fork();
if(cpid == 0) {
// child
} else {
// parent }
int cpid = fork();
if(cpid == 0) {
// child
} else {
// parent }
3/14/2017
CS/COE term 2174

6. Process identifiers (pids)
Every process has a unique numeric identifier, called its pid.
getpid() gets the pid of the current process.
getppid() gets the pid of the current process’s parent.
fork() returns the child’s pid in the parent.
You use pids as arguments to process-management syscalls.
For example, the waitpid() function waits for a child process to terminate (exit).
We’ll see that being used shortly!
3/14/2017
CS/COE term 2174

7. WHAT IF YOU CALLED FORK() IN A LOOP
DON’T,
lol
This is a forkbomb – a process which endlessly spawns new processes, bringing the system to a halt.
It’s usually accidental, but can be used as a form of DoS (denial-of-service) attack.
thoth has protection against this :^)
but still don’t do it :^)
You could get your account into a nasty state where Dr. Misurda has to reset it.
So DON’T.
3/14/2017
CS/COE term 2174

8. But… what if execvp() fails?
Changing identities
Making endless clones of the same process isn’t that useful.
We transform a child process with one of the exec*() functions.
Parent
Child
But… what if execvp() fails?
bash
Memory
bash
Memory ls
Memory
execvp()
fork()
3/14/2017
CS/COE term 2174

9. Error Handling in C
time for a tangent

10. What does it meeeeeean
If you look at the manpages for execvp, it says this:
If any of the exec() functions returns, an error occurred. The return value is -1, and errno will be set to indicate the error.
You’ll see similar descriptions for fork, open, close, read, write…
A return value of -1
Something called “errno”
In Java, if you try to open a file that doesn’t exist, what happens?
FileNotFoundException.
But C has no exceptions.
3/14/2017
CS/COE term 2174

11. In-band signaling
The C Way™ to report errors is to return some impossible value.
For many POSIX functions, this is a negative number.
In addition, syscalls (and some C library calls!) can put a value in a global variable (!) called errno.
It’s short for “error number.”
The Proper Way to Handle Errors™ therefore looks like:
int fd = open(“myfile.txt”, O_RDONLY);
if(fd < 0) {
int error = errno; // save errno
if(error == EEXIST)
// file already exists...
else if(error == ... // etc }
3/14/2017
CS/COE term 2174

12. “You mean we have to do that on every syscall?”
YEP.
I mean, unless you want a crashy, insecure program ¯\_(ツ)_/¯
Be sure to read the errors that a syscall can produce, then:
handle the ones you care about; and
fail gracefully for the errors you don’t handle.
The simplest method is “cry and exit.” Use strerror or perror:
int fd = open(“myfile.txt”, O_RDONLY);
if(fd < 0) {
perror(“couldn’t open myfile.txt”);
exit(1); }
3/14/2017
CS/COE term 2174

13. POSIX Process Destruction
back on track

14. Apoptosis, necrosis, and lysis
After a child process finishes exec*(), a few things could happen:
Both processes could live long, happy lives, and run forever.
The child could exit; or the parent could exit; or both could.
When I say “exit,” I mean one of the following possibilities:
The process exited normally (apoptosis)
The process crashed (necrosis)
The process was terminated by another process (lysis)
The parent can find out how the child exited through the status parameter of waitpid.
The manpages are your frieeeeeeends
Let’s see an example of a child process exiting two ways…
What are these mentions of “signals”?
3/14/2017
CS/COE term 2174

15. POSIX Signals

16. Polling vs. Asynchronous
Polling means “asking over and over if something happened.”
Asynchronous means “being notified when something happens.”
Polling
Asynchronous notification
3/14/2017
CS/COE term 2174

17. AAAA SIGINT!!! What’s a signal? normal_code(); nothing_unusual();
A signal is an asynchronous way the OS notifies your program of certain special events.
This happens outside the normal flow of execution.
In this way, signals are kind of like exceptions in Java.
When a signal is sent, the program runs a signal handler.
AAAA SIGINT!!!
normal_code();
nothing_unusual();
whatever();
if(blah == blah)
printf(“banana”);
void handler(int sig) {
printf(“O NO”); }
3/14/2017
CS/COE term 2174

18. Good signals to know
All the POSIX signals have names that start with SIG.
Many of the important ones have to do with process termination.
SIGSEGV is your friend, the segvfault!
SIGBUS is another kind of illegal memory access.
SIGILL is when an illegal instruction is executed.
SIGFPE is when a floating-point (or integer…?) error happens.
SIGABRT is caused by the abort() function.
SIGINT is the ctrl+C interrupt. Usually, it stops the program.
SIGTERM: “hey, time to quit, just letting you know”
SIGKILL: “nothin personnell… kid…”
This is serious business. The process is being terminated, NOW.
Signals aren’t all bad, though…
3/14/2017
CS/COE term 2174

19. Handling signals
You can catch signals by setting up a signal handler of your own.
You do that with the signal() function.
The first argument is the signal to handle.
The second is a function pointer to a handler, or:
SIG_IGN to ignore the signal;
SIG_DFL to perform the default action.
It works kinda weirdly. When your handler is called, it usually unsets the handler, so you have to re-set it in the handler to get the signal again.
But not for SIGALRM??? idk
3/14/2017
CS/COE term 2174

20. Sending and receiving signals
You can send signals from your program with the kill() function.
You give it a pid and a signal.
You can send signals from the shell with the kill command.
A common useful invocation is:
kill -9 pid
This sends the SIGKILL signal to a process.
3/14/2017
CS/COE term 2174