3 ms·

That’s not true. man 7 signal-safety

• loeg 4mo ago
  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.
  • deleted 4mo ago
    [deleted]
  • asveikau 4mo ago
    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 4mo ago
      > 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 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.