> When you press CTRL+z, under the hood kernel terminal driver sends a SIGSTOP signal to foreground processes
No it doesn’t. It sends SIGTSTP, which has the same default handler as SIGSTOP, but unlike SIGSTOP, the process itself can change the signal handler for SIGTSTP, potentially to do whatever it likes, including nothing at all.
If we're going down the rabbit hole of pedantry, you could also say CTRL+Z doesn't send SIGTSTP, it's just a character sent to your shell. The shell will often send a SIGTSTP, but it can do whatever it likes, including nothing at all.
That said, custom behavior for SIGTSTP is about as common as a shell environment that doesn't send SIGTSTP on ctrlz.
Well, if you really want to go down the rabbit hole...
The shell only gets CTRL+Z when it is in the foreground.
The tty driver, which contains a copy of the forground process group id, sees the CTRL+Z, and rather than buffering it to pass to the foreground process, interprets it to send a SIGTSP to the process group that is in the foreground. A well behaving program will either handle the SIGTSTP then send itself a SIGSTOP or just act as if SIGSTOP has been sent. Then a SIGCHLD will be sent to the parent process. (In this case the shell) which can then set another process group or process, including itself, to the foreground process.
Some of the details may vary depending on the terminal line discipline being used... but the important part here is:
The shell isn't actually getting the CTRL+Z, its handled by the tty/pty pair that is in charge of the input at the moment.
Being specific about which signal is sent, especially if it deals with important nuances such as whether you can change the handler or not, isn't pedantry.
Maybe a little bit OT, In z/OS, you can see if a process has been put to suspended state because some other process is eating cpu and it keeps historical data about it. Is there a way to achive same thing for Linux? I am reading brendangregg's performance book, however I could not see anything related to this so far.
No it doesn’t. It sends SIGTSTP, which has the same default handler as SIGSTOP, but unlike SIGSTOP, the process itself can change the signal handler for SIGTSTP, potentially to do whatever it likes, including nothing at all.