Why doesn't the Linux kernel send SIGCONT first and then SIGHUP to a newly orphaned process group containing a stopped process?

Question

APUE says

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).

The kernel sends SIGCONT after SIGHUP, but the process is waken up by SIGCONT before acting on SIGHUP. So why doesn't the Linux kernel send SIGCONT before SIGHUP?

Thanks.

Related to but not answered by Does the default action of SIGCONT resume the execution of a stopped process before or after first handling any pending unblocked signals?

---

I did not answer my question.

Answer 1

Not only do you answer your question, the link you added at the end also answers your question.

When a process is stopped, all signal processing is stopped, except for SIGCONT and SIGKILL - which are, in practice handled by the operating system.

This means that SIGHUP can only the handled after the process is resumed, which happens when SIGCONT is recieved and handled, so, even if you send a SIGHUP followed by a SIGCONT, they are going to be handled in the opposite order.

Now, in practice, the kernel sending SIGHUP before will result in less stuff being done by a process between handling SIGCONT and handling SIGHUP, as the second is already queued to be handled.