More About Processes

$ 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.

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.

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.

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?