The parent process id (ppid) of a process cannot be changed outside of the kernel; there is no setppid system call. The kernel will only change the ppid to (pid) 1 after the processes parent has terminated - if the process did not respond to a signal that the parent was terminated. For this to happen, the process needs to have ignored various signals (
SIGTERM, etc.) beforehand.
screen(1) has a very elegant means of handling detaching and reattaching. When you first start
screen, you are actually starting a user interface (ui), which by default will create a daemon (the session manager). This daemon has no terminal associated with it, a new process group (
setpgrp(2)), a new session id (
setsid(2)). The daemon, running as
SCREEN, will then create subprocesses connected to pseudo-terminals (
pty), then multiplexes the data from the ptys and the ui (
screen). The subprocesses think they are talking with a real terminal.
If the ui
screen terminates, the daemon
SCREEN will still be running, buffering data, handling signals, waiting for a new ui, etc. because it is a different process group and in its own session. When you reattach with a new ui
screen, then the daemon will continue to multiplex as it was doing before. The daemon will run continue running until all subprocesses terminate, is killed, a fatal bug is encountered or the host reboots.