Technical Women

002
Figure 1. Sophie Wilson

Three Packs a Day by Courtney Barnett

Today

  1. Finish IPC.

  2. File handles.

  3. Process life cycle:

    • Birth: fork()

    • Change: exec()

    • Death: exit()

    • The Afterlife: wait()

$ cat announce.txt

  • Today is the add/drop deadline!

  • Recitations start this week and office hours continue.

  • ASST1 is due in less than two weeks.

  • We will release changes to test161 later this week and restart the submission server.

A Note on Partnering

  • Both partners should be working together on each assignment.

  • Working effectively with others is a life skill. It involves a degree of patience and commitment by both parties:

    • Patience: not getting too far ahead of your partner and doing all the work

    • Commitment: not getting too far behind your partner and dropping the ball

  • Take ASST1 as your chance to test drive your partnership.

    • Feel free to approach the course staff for help if needed.

  • We do not let students form new partnerships. However, if you are really struggling then we can let you work alone on ASST2 and ASST3.

A Note on Grading

  • My goal is to help everyone "make an A."

  • If you are confused about anything, or have any doubts, email [email protected] and we will reply promptly.

A Note on Assignment Grading

  • This year we have removed many of the free points from the assignments—​particularly the code reading questions.

  • The goal is not to demoralize anyone. The goal is to ensure that you are working on the parts of the assignments that are important.

  • However, we strongly advise you to complete the recommended questions and exercises.

Last Time

We discussed the process abstraction.

  • Unfortunately at this point we are discussing an abstraction (processes) built on other abstractions (threads, address spaces, files) that we haven’t discussed yet!

  • There is a certain circularity to operating system design but we had to break through at some point.

  • Bear with me—​we will get there and we will also keep returning to the examples we’ve already introduced.

  • Questions about material presented Friday?

$ kill -9 ubshuttle # IPC: signals

signals

  • Signals are a limited form of asynchronous communication between processes.

  • Processes can register a signal handler to run when a signal is received.

  • Users can send signals to processes owned by them; the super-user can send a signal to any process.

  • Processes can ignore most signals.

    • SIGKILL is a notable exception; used for non-graceful termination.

    • SIGTERM is used for graceful shutdown.

We Will Return to IPC

  • return codes — we will discuss again when we learn about wait() and _exit().

    • You will implement return codes for ASST2.

  • pipes — we will discuss again when we learn about fork().

  • signals — are difficult to use and implement and not something we will return to.

  • shared memory — we will discuss again when we learn about address spaces and virtual memory.

Processes v. Threads

  • Potentially confusing due to overlapping terminology—​we can describe both a process and a thread as running.

  • Terminology can be helpful for remembering the distinction:

    • A computing process requires multiple resources: the CPU, memory, files, etc.

    • A thread of execution abstracts CPU state.

  • Processes contain threads; threads belong to a process.

    • Only one exception: the kernel may have threads of execution not associated with any user process

    • (Except the kernel process, which is a process, remember?)

  • A process is considered to be running when one or more of its threads are running.

  • Different operating systems use different terminology, but share common ideas.

Process Example: Firefox

Firefox has multiple threads. What are they doing?

  • Waiting for and processing interface events: mouse clicks, keyboard input, etc.

  • Redrawing the screen as necessary in response to user input, web page loading, etc.

  • Loading web pages—​usually multiple parts in parallel to speed things up.

Firefox is using memory. For what?

  • Firefox.exe: the executable code of Firefox itself.

  • Shared libraries for web page parsing, security, etc.

  • Stacks storing local variables for running threads.

  • A heap storing dynamically-allocated memory.

Firefox has files open. Why?

  • Configuration files.

  • Fonts.

$ top # more process information

top

Process Example: bash

  • Let’s do this for real using standard Linux system utilities.

Finding bash

finding bash

  • ps aux gives me all process, then grep for the one I’m after.

  • …​or, do it all in one shot using pgrep.

  • …​or, if I know it’s running in my current session a bare ps will do.

bash

process bash 3

$ ps -Lf # thread information

threads bash
What are:

  • UID: user the process is running as.

  • PID: process ID.

  • PPID: parent process ID.

  • PRI: scheduling priority.

  • SZ: size of the core image of the process (kB).

  • WCHAN: if the process is not running, description of what it is waiting on.

  • RSS: total amount of resident memory is use by the process (kB).

  • TIME: measure of the amount of time that the process has spent running.

$ ps -Lf # thread information

threads bash

  • If bash had multiple threads running this view would show them, so bash does not have multiple threads.

bash

process bash 2

$ ps # process information

  • I wish we could see a process with multiple threads…​

$ ps -Lf # thread information

ps threads

$ pmap # memory mappings

pmap

Next Time

  • fork and file handles

  • The process lifecycle:

    • birth (fork()),

    • change (exec()),

    • death (exit()), and

    • heaven (wait()).

← →