2 ms·
POSIX is frequently hyperconservative garbage. There's what POSIX allows, and there's what Linux and other real Unix systems actually allow. How do you think po
by quotemstr 7y ago
POSIX is frequently hyperconservative garbage. There's what POSIX allows, and there's what Linux and other real Unix systems actually allow. How do you think posix_spawnnp is implemented on systems that don't have a native system call for it? vfork(2)! close(2) in practice works fine.
I don't understand how you can claim that vfork can't be used correctly when there are thousands of existence proofs showing that it works fine.
- naniwaduni 7y ago> I don't understand how you can claim that vfork can't be used correctly when there are thousands of existence proofs showing that it works fine. As libc implementer, you're inherently OS- and probably compiler-bound, and you can either fudge it to work on the system you're writing for, or have enough clout to make it so. It's an implementation detail. As the author of a program which is not strictly OS-bound, you do not have this luxury. Even if you want it, you're probably better off calling clone(2) directly so that you won't get an unintended semantic. Without counting indirect uses via libc popen/system/&c., I do not believe there are "thousands" of correct uses of vfork. If we count distinct hand-written code paths that call vfork, I'd wager closer to a few dozen, with at best a handful outside of a libc. It's a hideous interface.
- quotemstr 7y agoI'm not suggesting that people use vfork over posix_spawn --- I'm objecting specifically to the claim that it can't be used correctly. It can be. Emacs uses it, portably, and the sky doesn't come crashing down.