[loeg]

You're talking about libc design choices, not constraints imposed by the kernel. To the kernel, a post-fork pre-exec process is just any old process. GP was suggesting post-fork processes were constrained in the syscalls they could invoke; they are not.

[asveikau]

I did not say they are constrained in what syscalls they can make, as if some nanny at the syscall entry point will punish you for doing wrong. I said that it interacts poorly with threads due to inherent race conditions. See the other comment.

[loeg]

> I said that it interacts poorly with threads due to inherent race conditions.

No, you absolutely did not: https://news.ycombinator.com/item?id=48427396

Literally nothing in that comment mentions or discusses threads.

> I did not say they are constrained in what syscalls they can make

You wrote: "The things you can do between fork and exec are sometimes underestimated. Off the top of my head, you can call dup2(), you can set a process group id, probably a few other things."

Those are all syscalls. You can also invoke any of the other ~hundreds of syscalls linux exposes, not only dup2, setpgid, and a "few" others.