Does kernel sending SIGHUP to a process group that becomes orphaned and contains a stopped process terminate all the processes by default?

In The Linux Programming Interface > To see why orphaned process groups are important, we need to view > things from the perspective of shell job control. Consider the > following scenario based on Figure 34-3: > > 1. Before the parent process exits, the child was stopped (perhaps because the parent sent it a stop signal). > > 2. When the parent process exits, the shell removes the parent’s process group from its list of jobs. The child is adopted by init and > becomes a background process for the terminal. The process group > containing the child is orphaned. > > 3. At this point, there is no process that monitors the state of the stopped child via wait(). > > Since the shell did not create the child process, it is not aware of > the child’s existence or that the child is part of the same process > group as the deceased parent. Furthermore, the init process checks > only for a terminated child, and then reaps the resulting zombie > process. Consequently, the stopped child might languish forever, since > no other process knows to send it a SIGCONT signal in order to cause > it to resume execution. > > Even if a stopped process in an orphaned process group has a > still-living parent in a different session, that parent is not > guaranteed to be able to send SIGCONT to the stopped child. A > process may send SIGCONT to any other process in the same session, > but if the child is in a different session, the normal rules for > sending signals apply (Section 20.5), so the parent may not be able to > send a signal to the child if the child is a privileged process that > has changed its credentials. > > To prevent scenarios such as the one described above, SUSv3 specifies > that **if** a process group becomes orphaned and has any stopped members, > **then** all members of the group are sent a SIGHUP signal, to inform > them that they have become disconnected from their session, followed > by a SIGCONT signal, to ensure that they resume execution. If the > orphaned process group doesn’t have any stopped members, no signals > are sent. The default action to SIGHUP is termination. So does kernel implicitly sending SIGHUP to a process group that becomes orphaned and contains a stopped process mean that - those processes in the group and without their own SIGHUP dispositions will be terminated? Will any stopped process in the group be first resumed by SIGCONT and terminated by SIGHUP? - to make the processes in the group survive, they need to have their own SIGHUP dispositions or ignore SIGHUP? Thanks.