HELLER@cs.umass.EDU.UUCP (03/19/87)
I have some random questions about the use of fork(). Are there reasons for using fork() other than ones having to do with certian limitations of UNIX, such as lack of asynchronious I/O and process creation parameters to functions like execv() et. al. (things like priority and I/O binding)? I am curious to know whether there really is any reason for trying to implement a UNIX-style fork() in an O/S like OS-9/68K or CDOS-68K. That is if the various non-fork() type subprocess creating functions had the nesscesary additional arguments and the I/O system provided some sort of user-accessable asynchronious I/O access, would a UNIX-style fork() still be neccessary or usefull for anything? Robert Heller ARPANet: Heller@UMass-CS.CSNET BITNET: Heller@UMass.BITNET BIX: Heller GEnie: RHeller FidoNet: 101/27 (Dave's Fido, Gardner, MA) or 101/147 (Orange Fido, Orange, MA) CompuServe 71450,3432 Local PV VAXen: COINS::HELLER UCC Cyber/DG: Heller@CS
mwm@VIOLET.BERKELEY.EDU.UUCP (03/21/87)
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? <mike
bsteve@gorgo.UUCP (on Monster Island) (03/23/87)
mwm@violet.berkeley.edu wrote - 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. This seems highly reasonable and probably should have been there all along. >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. The only gotcha here is the issue of signal handling between processes. If the parent ublock and ptable stuff stick around is it possible for the parent to take the signals meant for the child? PS - this sounds very much like mach eh? Steve Blasingame (Oklahoma City) ihnp4!occrsh!gorgo!bsteve bsteve@eris.berkeley.edu
louden@GATEWAY.MITRE.ORG.UUCP (03/23/87)
fork would still be needed to allow a clean access to more than one stack for simulated(or real) parallel processing.
mouse@mcgill-vision.UUCP.UUCP (03/31/87)
In article <8703210641.AA09391@violet.berkeley.edu>, mwm@VIOLET.BERKELEY.EDU (Mike Meyer, No one lives forever.) writes: [ stuff about how using fexec() because it covers 99% of the cases is a bad idea - I agree. ] > What I prefer is two system calls: > 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 Heavens no. Do you realize what concurrent execution with shared stack segments means?! Shared text is OK, and is in fact used. Shared data can be useful but is normally a pain for tasks where you want fork() but not fexec(). Shared stack is a disaster, *unless*, as in BSD vfork(), one process waits until the other exit()s (or exec()s). Even then, vfork() is annoying in its restrictions. fork() is nice when you want to keep all the code in one process (fexec() requires having the child's program in another file somewhere, and wiring its name in somehow - using fork() means the binary is self-contained and more portable). der Mouse Smart mailers: mouse@mcgill-vision.uucp USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!musocs!mcgill-vision!mouse think!mosart!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu