For instance event based programming, "epoll" should replace "select". Synchronous programming, signalfd, timerfd, etc... but then "signals" should be more accurately classified, for instance in monothreaded applications segfault won't be delivered from a "signalfd" in a "epoll" syscall... and why not keep only the "realtime signal" behavior?
If POSIX only "add" new "options", in the end, you'll get gigantic spec just being the mirror image of the very few implementations since its size will make it unreasonable for a new implementation from scratch.
The "leaner POSIX" route seems the right way here, but it is really easier to say than to do.
fork() should be ditched.
1. Call a function that creates an empty child process in a suspended state.
2. Call functions that: map/write memory into the child process’s address space; add file descriptors to the child process; set the child process’s initial register values; and so on.
3. Call a function to unsuspend and run the child process.
The reality is fork() is pretty much exclusively used to launch new processes these days, outside a few specific cases. Today, it's a poor fit for that problem. And the answer is what Windows has been doing (and POSIX has now had) for a long time: explicitly launching processes by giving a handle/pathname to an executable like posix_spawn. That's the first solution, anyway; a better one would be more capability-oriented design where you have to supply a new address space with all its resources yourself.
This HotOS paper is a pretty good detailed coverage of the argument; I find it very convincing. If fork() went away, I honestly wouldn't miss it, I think. https://www.microsoft.com/en-us/research/uploads/prod/2019/0...
fork() plays havoc with threads. If you want to start a new process, specify a fresh process image.
What does that mean?
> isn't thread safe
True but it's not meant to be. I'm not sure there are many if any valid use cases for forking and not immediately exec-ing and using threads together in the same application.
> insecure by default (inherits env/fds)
Inherits env and open file descriptors by design. It's pretty much always been understood that if you fork in most scenarios you immediately exec. You can set file to close on exec and set a new env if desired, and not do that if it's not.
> and it's also slow with all the state it must copy.
I thought it was mostly COW?
> And at a conceptual level it doesn't work in environments where the nature of a "process" and "address space" aren't synonymous.
Yeah valid argument. posix_spawn man page says:
> "The posix_spawn() and posix_spawnp() functions are used to create a new child process that executes a specified file. These functions were specified by POSIX to provide a standardized method of creating new processes on machines that lack the capability to support the fork(2) system call. These machines are generally small, embedded systems lacking MMU support.".
posix_spawn is POSIX and has existed along side fork since POSIX.2001. So your saying you want every application ever written to be automatically portable to systems the can't support fork, therefore get rid of fork entirely? I guess.
My point was that embryonic processes aren't really the right solution since they require exposing a whole bunch to powerful primitives like read/write of remote address spaces in order to spawn processes. That ends up being slow (because each one of those calls is necessarily a syscall and requires manipulating page tables to mess with the other process). It also means to prevent abuse you need to be very carefully control when to revoke those privileges.
The obvious solution is to take all the operations you would have done to the remote process, encode them in some form, and pass them off to a secure agent (in this case the kernel) that can do them in bulk. That solves both perf issues (1 syscall, and no repeated round tripping through multiple address spaces), and the security issue (you no longer need to expose primitives to manipulate the remote process to every process that is allowed to spawn a new one).