A process group is a collection of one or more processes, usually associated with the same job, that can receive signals from the same terminal.
Each process group have a leader process. The leader is identified by its process group ID being equal to its process ID.
The process group still exist as long as at least one process is in the group, regardless of whether the group leader terminates.
A process can set the process group id of itself or any of its children. Furthermore it can't change the process group id of one of its children after that the child has called one of the exec functions.
The process group id is inherited by the child. Usually the process group id is set as equal to the process id before the call to one of the exec functions.
The processes in a process group are usually placed there by a shell pipeline.
pid_t getpgid(pid_t pid); pid_t getpgrp(void); /* equivalent to getpgid(0) */ int setpgid(pid_t pid, pid_t pgid);
In most job-control shells, the
setpgid() function is called after a fork to
have the parent set the process group ID of the child, and to have the child
set its own process group ID.
One of these calls is redundant, but by doing both, we are guaranteed that the child is placed into its own process group before either process assumes that this has happened. If we didn’t do this, we would have a race condition, since the child’s process group membership would depend on which process executes first.
A session is a collection of one or more process groups.
A session leader is the process that creates a session. When a process creates a new session it also creates a new process group, thus becomes the group leader as well.
An individual process disconnects from its controlling terminal when it creates a new session. Thus the session leader has no controlling terminal.
To create a new session the process must not be a process group leader.
A session can have a single controlling terminal. This is usually the terminal device.
The session leader that establises the connection to the controlling terminal is called the controlling process.
The process groups within a session can be divided into a single foreground process group and one or more background process groups.
If a session has a controlling terminal, it has a single foreground process group.
Whenever we press the terminal interrupt key (Control-C) the interrupt is sent to all processes in the foreground process group.
Whenever we press the terminal's quit key (Control-backslash), the quit signal is sent to all processes in the foregroun process group.
If a modem (or network) disconnect is detected by the terminal interface, the hang-up signal is sent to the controlling process (the session leader).
Child processes created by with fork inherit the controlling terminal.
The way a program guarantees that it is talking to the controlling terminal is
to open the file
/dev/tty. This special file is a synonym for the controlling
Get process group ID of foreground process group associated with the terminal open on fd.
If athe process has a controlling terminal, the process can call
set the foreground process group ID to pgrpid. The value of
pgrpid must be the
process group ID of a process group in the same session, and fd must refer to
the controlling terminal of the session.
tcsetpgrp(int fd, pid_t pgrpid);
A job is a group of processes. Job control allows to start multiple jobs from a single terminal and to control which jobs can access the terminal and which jobs are run in the background.
Requires three forms of support:
If a background job tries to read from the terminal, the terminal driver sends
a special signal to the background job:
SIGTTIN. This signal normally stops
the background job.
If a background job tries to write to a terminal, the result depends on the
settings of the terminal (stty). The terminal can be configured to write to the
standard output or to send a
SIGTTOU signal, stopping the job.
Is a process group in which the parent of every member is either itself a member of the group or is not a member of the group's session.
If a process group is not orphaned, there is a chance that one of those parents will restart a stopped process. Otherwise the process will not continue the execution.
To solve the problem, as soon as a process group goes orphaned, POSIX.1 requires that a SIGHUP followed by a SIGCONT is sent to every process in the group. This causes the child to be continued. The default action to the SIGHUP is to terminate the process.
DOMANDA: se il padre e' membro del gruppo, anche se orfano, non pue' risvegliare il figlio stoppato?