[sigstop] sigstop while kernel TCP stack per process continues to receive package

Reference:

What happens to requests to a service that is stopped with SIGSTOP


From the point of view of any part of the system that isn't concerned with the process's state and stats, a process that is stopped (i.e. won't be scheduled until it receives a SIGCONT) is indistinguishable from a process that's running, but isn't responding to a particular query.

While the process is stopped, there's no such thing as a timeout in the process. There are usually no timeouts in the network stack either: the packet has been received by the machine, even if it hasn't gotten to the machine. As far as e.g. TCP transmission is concerned, the packet has been received and it's up to the application to respond.

If the socket's buffer fills up, the network stack will start dropping packets.

There's no reason why the behavior of the network stack would depend on the process's state. The process could come out of the stopped state at any time. There could be multiple processes listening on a socket, so any decision based on the process state would have to take all of them into account.