Skip to main content

Why should fork() have been designed to return a file descriptor? [Resolved]

On his web page about the self-pipe trick, Dan Bernstein explains a race condition with select() and signals, offers a workaround and concludes that

Of course, the Right Thing would be to have fork() return a file descriptor, not a process ID.

What does he mean by this -- is it something about being able to select() on child processes to handle their state changes instead of having to use a signal handler to get notified of those state changes?

Question Credit: Lassi
Question Reference
Asked July 21, 2019
Posted Under: Unix Linux
3 Answers

Bernstein doesn't give much context for this "Right Thing" remark, but I'll hazard a guess: having fork(2) return a PID is inconsistent with open(2), creat(2) etc returning file descriptors. The rest of the Unix system could have done process manipulation with a file descriptor representing a process, instead of a PID. A system call signalfd(2) exists, which allows a somewhat better interaction between signals and file descriptors, and shows that a file-descriptor-representing a process could work out.

credit: Lassi
Answered July 21, 2019
Your Answer