The Linux Programming Interface says
The ioctl(fd, TIOCNOTTY) operation can be used to remove a process’s association with its controlling terminal, specified via the file descriptor fd. After this call, attempts to open /dev/tty will fail. (Although not specified in SUSv3, the TIOCNOTTY operation is supported on most UNIX implementations.)
If the calling process is the controlling process for the terminal, then as for the termination of the controlling process (Section 34.6.2), the following steps occur:
All processes in the session lose their association with the controlling terminal.
The controlling terminal loses its association with the session, and can there- fore be acquired as the controlling process by another session leader.
The kernel sends a SIGHUP signal (and a SIGCONT signal) to all members of the foreground process group, to inform them of the loss of the controlling terminal.
Assume a session has a controlling terminal.
Assume a process in the session calls
ioctl(fd,TIOCNOTTY) to remove its association with its controlling terminal.
Does that mean that controlling terminal is a per-process concept? In a process session, can some process can have a controlling terminal while some don't? (Note that https://unix.stackexchange.com/a/405780/674 says that controlling terminal is a per-process-session concept.)
Can't a process which has removed its controlling terminal be sent signals related to the controlling terminal, such as SIGHUP, while those processes which still have their controlling terminals can still be sent signals related to the controlling terminal?
When "all processes in the session lose their association with the controlling terminal", does it imply that "the controlling terminal loses its association with the session"? Or do we still need to do something so that "the controlling terminal loses its association with the session"? In other words, do we need to perform dis-association from both sides (processes and terminal), or just one side (processes or terminal)?