4 ms·
Calling that elegant is a path dependence of the history of fork+exec. In an alternative world where fork+exec never existed, a lot of those "usual APIs" would
by jcranmer 5mo ago
Calling that elegant is a path dependence of the history of fork+exec.
In an alternative world where fork+exec never existed, a lot of those "usual APIs" would probably have had an explicit pid argument to them that let you modify process configuration from a different process. (This is how Fuschia works, e.g.). There's a lot of benefit to this world: the most obvious is that you don't have to magic up some IPC system just to report configuration errors, but there's actually a good amount of utility in being able to have a manager process that is tweaking attributes of its children (e.g., debuggers would love it).
- uecker 5mo agoWeren't there enough parallel paths of development in this world?
- trumpdong 5mo agoOr you could call ptrace_syscall (that doesn't currently exist) on your child processes that you are tracing because you'd always be tracing them by default, or get an io_uring for the child process, or...
- uecker 5mo agoA ptrace_syscall would be interesting and would seem to be a full replacement for having the pid argument everywhere. But frankly, I am not really seeing the value.
- trumpdong 5mo agoThe value is not needing to change every other syscall and not needing to write new ones with a pid argument (besides which, what when you want to change it to a pidfd argument? then you add pidfd_syscall instead of duplicating every syscall again)