🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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()
#206
Author: mwm
Date: Sat, 21 Mar 1987 06:41
48 lines
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()
#217
Author: mouse
Date: Tue, 31 Mar 1987 00:08
33 lines
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