Signalling Process Groups
Processes (under Unix, at least) are organized into process groups, generally corresponding to
an entire job. For example, when you fire off a single shell command
that consists of a series of filter commands that pipe data from one to
the other, those processes (and their child processes) all belong to the
same process group. That process group has a number corresponding to the
process number of the process group leader. If you send a signal to a
positive process number, it just sends the signal to the process. But if
you send a signal to a negative number, it sends that signal to every
process whose process group number is the corresponding positive
number—that is, the process number of the process group leader.
(Conveniently for the process group leader, the process group ID is just
$$.)
Suppose your program wants to send a hang-up signal to all child
processes it started directly, plus any grandchildren started by those
children, plus any great-grandchildren started by those
grandchildren, and so on. To do this, your program first calls setpgrp(0,0) to become
the leader of a new process group, and any processes it creates will be
part of the new group. It doesn’t matter whether these processes were
started manually via fork,
automatically via piped opens, or as
backgrounded jobs with system("cmd
&"). Even if those processes had children of their own, sending a hang-up signal to your entire process group will find them all (except for processes that have ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access