Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mcnc!rti!xyzzy!throopw From: throopw@xyzzy.UUCP (Wayne A. Throop) Newsgroups: comp.unix.questions Subject: Re: Fork and Join, Pipe in C Message-ID: <124@xyzzy.UUCP> Date: Thu, 2-Jul-87 10:25:00 EDT Article-I.D.: xyzzy.124 Posted: Thu Jul 2 10:25:00 1987 Date-Received: Sat, 4-Jul-87 05:59:40 EDT References: <7737@brl-adm.ARPA>, <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <113@xyzzy.UUCP> <22256@sun.uucp> Organization: Data General, RTP NC. Lines: 65 > guy%gorodish@Sun.COM (Guy Harris) >> throopw@xyzzy.UUCP (Wayne Throop) >> But fork() can *never* be as efficent as vfork(), and sometimes this >> efficency is crucial. > Yes, there is a savings if you can avoid copying the VM data > structures, but this savings will be less than the savings from not > copying the pages themselves. I'm not convinced that this savings > will necessarily be enough to justify "vfork". I wish to make clear that I'm not convinced of this either. Rather than defending vfork, I was attempting to suggest that the alternative of a create_process() operation was preferable. The justification for vfork is loosely that the fork of a command processor to create a child process is most often followed immediately by an exec, and thus a brain-damaged fork will do just fine for these cases. My answer is that it is better to glue the two together so that the brain-damage cannot possibly bite anyone. Guy does point out an interesting thing about the "gap" between the fork and the exec, however: > If the program to be run in the new process is not to inherit its set > of open files from its parent, the child process has to rearrange the > file descriptors before doing an "exec". Actually, this can all be done in the parent, for most common cases. The point is that create_process() would act like exec() in that the child process would close descriptors marked for close-on-exec, and most file-descriptor-twiddling is reversible, and hence *can* (at some quite small cost) be done in the parent and then reversed after the create_process(). Thus, the alternative of making the create_process() have every bell and whistle for file control duplicated as part of the call is not really necessary. And in those cases where it cannot be done in the parent because of the complication of the inter-fork()-exec() processing, well... you'll just have to pay the price of a fork, won't you? Many may be skeptical that the processing can be done in the parent. I can't afford this skepticism, since I participlated in coding many of the common cases with the file manipulation done in the parent process. In particular, in popen() and similar library routines, and in the two shells. The shells, of course, are the most difficult, and try to squeeze an indecent amount of processing into the space between the fork() and the exec(), which is probably why berkeley implementors chose to do vfork() rather than grit their teeth and gird their loins and perform all *kinds* of mental preparation via divers asceticisms and go in there and *fix* *the* *blasted* *shells*. I sympathize with this decision, but I regret the outcome, which is unclean vfork() instead of relatively (I emphasize: *relatively*) clean create_process(). (I realize that making changes in the parent and then reversing them opens a small window of vulnerability where asynchronous events can find the process with its pants down, but *that* is just a bug in the way asynchronous events (signals et al) are specified to work in Unix. But that's another story.) -- You find sometimes that a Thing which seemed very Thingish inside you is quite different when it gets into the open and has other people looking at it. --- A. A. Milne, Winnie-the-Pooh. -- Wayne Throop !mcnc!rti!xyzzy!throopw