Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!VIOLET.BERKELEY.EDU!mwm From: mwm@VIOLET.BERKELEY.EDU.UUCP Newsgroups: mod.computers.68k Subject: Re: Questions about the use of fork() Message-ID: <8703210641.AA09391@violet.berkeley.edu> Date: Sat, 21-Mar-87 01:41:50 EST Article-I.D.: violet.8703210641.AA09391 Posted: Sat Mar 21 01:41:50 1987 Date-Received: Sun, 22-Mar-87 22:13:11 EST Sender: mwm@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 48 Approved: info-68k@ucbvax.berkeley.edu 99% of the uses of fork are followed by a few standard file i/o re-arrangements, or by nothing, before an exec. These can all be adequately covered by a fexec (fork + exec) type call, providing it gives you some hooks to re-arrange the environment. But the result is sort of like the MVS file system compared to the Unix file system. On Unix, a file is a stream of bytes, and you are free to lay whatever structure you want on top of it. Of course, you have to do the work. On MVS, files come in a large set of flavors. Large, but fixed. It does all the work for you for the structure it provides, but if you need a structure that's not there, you're screwed. Likewise, fork/exec gives you the _total_ environment to play with in any way you want. A fexec only lets you change what the designers decided you needed to change. Note that fexec can be simulated with fork/exec, but not vice-versa. Calling the lack of a fexec in Unix a limitation is wrong. It was designed to give you much more power than that. In the original environment (64K-max processes with an MMU + hard disk), it was fast elegant. In the environment under discussion (1/2Meg+ processes, and no MMU, and maybe no hard disk) it's elegant, but a PAIN to implement, and slow when it's done. What I prefer is two system calls: 1) fexec - run another process in a fork, with a block describing how the environment should be modified on the way. As stated above, this does what you want for a new process most of the time. Note that you still need a Unix exec()-like call, but that can be done by fexec() followed by the parent exiting. If fexec can be structured correctly, it would be nice to proivde this as a system call, thus saveing process creation/exit overhead, and probably more. 2) newthread - roughly, vfork in 4BSD. This creates another process that shares all resources with the parent. If either one does an exit() (or exec()) the other one just continues. YOu probably want to schedule the child to run first. Some technic for rendezvous will be required. Newthread gives you the capabilities of Unix fork/exec, you just have to take more care about things. It should cover all the cases you want fork for. Of course, the cases you want it for fork/exec Comments?