johnl@esegue.segue.boston.ma.us (John R. Levine) (07/07/90)
In article <3830012@hpcupt1.HP.COM> renglish@hpcupt1.HP.COM (Robert English) writes: >Finally, all of this discussion misses the point that the normal >performance-critical sequence is a fork followed by some kernel data >structure manipulations and an exec, and that both performance and >purity could be achieved by providing a single system call that performs >the whole sequence. The problem is that the manipulations between the fork and the exec can be extremely complicated, involving opening and closing files, rearranging file descriptors, turning setuid and setgid on and off, and a raft of other things. A useful combined fork/exec needs enough options to do any of the manipulations you'd do in C code, and the "run" calls that I've seen in real systems are indeed extremely complex. Moreover, each time you add another piece of per-process context, you have to add another option to the run call. Yuck. One plausible scheme that has been suggested is to have every call that changes the context take a PID argument, with the default being to do it to your own process. Then the run call needs only one option, "freeze", so the parent can do all of the context munging and then unfreeze it. That would work, but at the cost of adding an extra argument to every open, dup, etc., and at the more serious cost of having to define a whole set of protection rules about who is allowed to change whose context when. It's not trivial -- for instance, if a parent could arbitrarily fiddle its children's context it would make setuid programs totally insecure. It seems to me that separating the fork and exec was a brilliant idea because it provides a clean way to to subprocess context manipulation using the same programming languages and calls that are already present. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl Marlon Brando and Doris Day were born on the same day.