Hacker News new | ask | show | jobs
by CGamesPlay 319 days ago
Child processes are created using, generally, 2 syscalls: fork, then exec. When you fork, all file descriptors the main process has open are copied, and are now open in two places. Then, when the child calls exec (to transform itself into the target program), all file descriptors stay open in the new process (unless a specific fd is explicitly configured otherwise, FD_CLOEXEC).

Standard output are just file descriptors with the number 0, 1, and 2, and you can use the dup2 syscall to assign those numbers to some pipes that you originally created before you fork. Now the standard output of your child process is going to those pipes in your parent process. Or you can close those file descriptors, which will prevent the child process from reading/writing them at all. Or you can do nothing, and the copied file descriptors from the parent still apply.

Conceptually, you think of "spawning a child" as something that is in some kind of container (the parent process), but the underlying mechanics are not like this at all, and processes don't actually exist in a "tree", they just happen to keep a record of their "parent process ID" so the OS knows who to notify when the process dies.
2 comments
zokier 318 days ago
> Conceptually, you think of "spawning a child" as something that is in some kind of container (the parent process), but the underlying mechanics are not like this at all,

That is not quite right either, the newly created child processes generally go to the same process group as the parent, the process groups (and sessions) forming those "containers".

Tbh this is one of the many murky areas of UNIX.

link
CGamesPlay 318 days ago
My explanation definitely glosses over some details, but a process group isn't really a "container" in any meaningful sense, either. It can be left by any member (who can form a new process group completely unrelated to its old one, setsid), which resets the "controlling terminal" but isn't related to the standard output channels at all.
link
burnt-resistor 319 days ago
fork() when followed by exec*() is generally inefficient. That's why vfork(), clone(), and clone3() exist. There's no point in duplicating (even CoW) the entire kernel side and libc internal state of a process if it's going to be replaced with exec*() by a new, unrelated process.
link