Why do we need to send SIGHUP to a newly orphaned process group containing a stopped process?

The [Advanced Programming in the UNIX Environment](http://www.apuebook.com/) book ("APUE") says > Consider a process that forks a child and then terminates. Although this is nothing abnormal (it happens all the time), what happens if the child is stopped (using job control) when the parent terminates? How will the child ever be continued, and does the child know that it has been orphaned? > ... > If the process group is not orphaned, there is a chance that one of those parents in a different process group but in the same session will restart a stopped process in the process group that is not orphaned. > ... > Since the process group is orphaned when the parent terminates, and the process group contains a stopped process, POSIX.1 requires that every process in the newly orphaned process group be sent the hang-up signal (SIGHUP) followed by the continue signal (SIGCONT). If the concern is only that a stopped process won't have a chance to be waken up after its process group becomes orphaned, why doesn't the kernel just send SIGCONT when its process group becomes orphaned, and why need to send SIGHUP too?