By default, SIGHUP has no signal handler, and so a process that receives it will exit. The kernel should send SIGHUP to all child processes when you quit the shell session or the terminal file (pty/tty) is closed. Processes trying to write to a nonexistent terminal may be terminated by SIGPIPE.
So you launch a process with nohup(1). This puts SIGHUP and others on ignore status, redirects output to a file, and then executes your process. This is similar to how a daemon starts, when it explicitly dissociates from any terminal device.
With tmux or screen, a layer of pseudo-ttys (ptys) is created, and process groups are managed, so your terminal's pty is only connected to the master tmux process, and each subprocess/window is assigned a new pty and process group of its own, as if you had remotely logged in to each shell.
So tmux is now handling SIGHUP and can detect when your terminal or session closes out. The persistence of subprocesses comes from the fact that they aren't receiving SIGHUP and that they are still associated with pty, as tmux is running "daemonized" until you reattach.
So you launch a process with nohup(1). This puts SIGHUP and others on ignore status, redirects output to a file, and then executes your process. This is similar to how a daemon starts, when it explicitly dissociates from any terminal device.
With tmux or screen, a layer of pseudo-ttys (ptys) is created, and process groups are managed, so your terminal's pty is only connected to the master tmux process, and each subprocess/window is assigned a new pty and process group of its own, as if you had remotely logged in to each shell.
So tmux is now handling SIGHUP and can detect when your terminal or session closes out. The persistence of subprocesses comes from the fact that they aren't receiving SIGHUP and that they are still associated with pty, as tmux is running "daemonized" until you reattach.