Published this morning, forgot to toot about it:
1. exec would be useful even without fork
2. CLOEXEC is not a hack, at least not more than inheritable capability set.
3. memory overcommitment is a feature, would exist even without fork, and can be disabled with a sysctl knob
4. AFAIK the NT kernel has neither rfork/clone nor exec, which IMO sucks.
You can implement spawn with clone+exec, but can't implement exec with clone+spawn, or clone with spawn+exec. So you need clone and exec anyway.Spawn is at most a special case optimisation
>exec would be useful even without fork
>CLOEXEC is not a hack, at least not more than inheritable capability set.
CLOEXEC predates rfork-like approaches, it's totally a hack
> memory overcommitment is a feature, would exist even without fork, and can be disabled with a sysctl knob
I know, this doesn't change my arguments much. Fork was the impetus for overcommittment, and more rationale was added later iiuc
>You can implement spawn with clone+exec
IMO even if you have rfork or spawn, you still want to sometimes exec (and not spawn) an untrusted binary that shouldn't have access to some of your FDs.
As for memory overcommitment, I bet someone would invent it sooner or later, but maybe the default setting would be different.
As for implementing spawn with clone+exec, it'd be inefficient, yes, but would eventually lead to the same state.