otherworld

Process group

4 min read

A way to associate Processes together. Can never be empty e.g. must contain at least one process.

  • If a Signal is sent to a process, the kernel also sends the signal to all processes within the same process group. This is why the Ctrl+C SIGINT signal is passed to the child process as well.
  • When we fork() a process, the child and parent are placed in the same process group.

Process group ID (PGID)

Each process group also has a specific ID, just like a PID. Importantly, the PGID of a process is set from an initial PID, which is the PID of the process that forked.

  • If there are multiple processes in a group, and the initial process finishes, the PGID of the other processes remain the first PID.
    • Furthermore, even though the initial process has terminated, its PID cannot be reused because it’s still reserved until the process group is also done.

Modifying the PGID

setpgid(pid_t pid, pid_t pgid);
getpgid(pid_t pid);

Use setpgid() and getpgid() to get and set the PGID for a process. The syscalls do special things if we pass in 0 to one or more parameters; check man.

Changing PGID after calling exec() is not allowed

This will result in a failed setpgid() call with an EACCES error.

If we’re trying to change the PGID of a child process, this is a race condition because we’re at the mercy of the Scheduler, and exec() may be called before setpgid().

The solution is to call setpgid() from both the child and parent process, before the exec().

Using the PGID

Can send a signal via kill() to a whole process group by sending -pgid instead of pid. E.g. kill(-101, SIGINT). Why negative? It differentiates between sending a PID versus a PGID.

If we pass in -pgid to waitpid(), this makes it wait for any process in the group.

Session

A session is a collection of process groups. It is usually associated with a login or an instance of an open terminal, meaning that each login/terminal is a singular session.

  • If a session is attached to a controlling terminal, then only one process group can have control of it. This is related to the foreground process group. More below.
  • If the session is not attached to a terminal, it’s called a daemon.

Foreground and background processes

Sessions with controlling terminals split processes into two categories.

  • Background processes don’t have access to the terminal, and cannot read from it as an input.
  • Foreground processes can both read and write. AFAIK “controlling the terminal” and “being in the foreground” are the same. This means only one process group can be in the foreground.

Changing the foreground group

tcsetpgrp(int fd, pid_t pgrp);

A foreground process group can make another group the foreground using tcsetpgrp(). You would pass in the file descriptor associated with the terminal’s stdin.

Background processes have limited control

If a background process attempts to read from stdin, the OS will send the SIGTTIN signal to that process. The default disposition of this signal is to stop the program.

While it cannot read from the input, it can write to stdout.

If a background process calls tcsetpgrp(), the OS sends the entire process group a SIGTTOU signal. The default signal disposition is to stop the program.

  • The calling process can block or ignore the signal instead, which would allow the syscall to go through. This is necessary, for example, when the shell needs to take back control of the terminal after the child process finishes executing.

Job

The shell has the notion of a “job” which are commands that were started interactively.

  • I think by default when we start a job, it becomes the new foreground process group.
  • We can start a background job by appending the command with a &. This allows us to concurrently run other commands in the shell.

All processes within the same job are also in the same process group. How could there be multiple processes in a single job, when all we did was run a single command? Some possible ideas:

  • We’re using Pipes in the command, which necessitates running multiple commands
  • Singular programs may fork in order to perform their job

If we’re implementing a shell, we would need to make sure that any child processes created as a result of the interactive command are placed within the same process group.

Graph View

Backlinks