zlacker

>>jsnell+(OP)
Richard Stallman POSIX now will have to do one of the hardest stuff in the software realm: resist planned obsolescence while replacing some interfaces with "in-the-end better" interfaces, that on the long run. This is extremely though: often, replacing "in-the-end better" interfaces is actually planned obsolescence.

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.

>>sylwar+Zk
No, I/O completion ports (which Linux only recently got a form of) should replace epoll and select.

fork() should be ditched.

>>bitwiz+2F
> fork() should be ditched.

Why? In favor of what?

>>thetea+Kg1
Something like windows CreateProcess or posix_spawn().

fork() plays havoc with threads. If you want to start a new process, specify a fresh process image.

>>bitwiz+ds1
so does posix_spawn, since you can leak file descriptors into parallel spawning threads/processes before the execve (where they are closed if having O_CLEXEC).

>>matu3b+FE1
Yeah, that is a problem, and it is totally fixable. Checkout `POSIX_SPAWN_CLOEXEC_DEFAULT` on macOS for an example. Again, just because there are API deficiencies doesn't mean that the idea is wrong.