Thread View: mod.computers.68k
2 messages
2 total messages
Started by mwm
Sat, 21 Mar 1987 06:41
Re: Questions about the use of fork()
Author: mwm
Date: Sat, 21 Mar 1987 06:41
Date: Sat, 21 Mar 1987 06:41
48 lines
2925 bytes
2925 bytes
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
Re: Questions about the use of fork()
Author: mouse
Date: Tue, 31 Mar 1987 00:08
Date: Tue, 31 Mar 1987 00:08
33 lines
2314 bytes
2314 bytes
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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads