🚀 go-pugleaf

>The earlier mention was right; a OS-9 process's data memory does not get
>moved.  (Of course, 99.9+% of programs under Unix that use fork() read

>	if (fork() == /* whatever says I'm the child */)
>		exec[a-z]*("what I really wanted to run", ...);

>so I don't think that OS-9's at any great loss for not having Unix's
>fork().)

I partly agree, but I would like to have both the OS9 fork() construct
with exec() built-in as well as the unix fork(). Given the more recent
implementations of UNIX that use virtual memory and copy-on-write, to
allocate data segments the overhead of the UNIX fork() is much reduced.
This does not preclude the *large* additional overhead of the additional
system call to exec().

The reasoning for having the OS9 fork() is very straightforward. It is
much simpler to use and is what you need much of the time. The need for
the UNIX fork()/exec() construct comes into play when one wishes to perform
changes in the process environment (a.k.a signals or io-controls) before
actually loading the child process. A good example of this has to do with
the creation of children that one doesn't wait() on. You may wish to direct
particular signals to a particular process. Consider the following example:


		/* fork a child process to invoke notes on the
		 * notesfile msg.username for the selected user
		 */
		if (!(pid=fork())) {
			signal(SIGCLD, SIG_DFL);
			execle("/usr/bin/notes","",answer,0,environ);
		} else {

			/* turn off signals in the parent process */
			isave= (int) signal(SIGINT, SIG_IGN);
			hsave= (int) signal(SIGHUP, SIG_IGN);
	
			/* wait for child process to complete */
			(void) signal(SIGCLD, SIG_DFL);
			while ((retval=wait(&status)) != pid) ;
			(void) signal(SIGCLD, SIG_IGN);
	
			/* turn back on (void) signals in the parent process */
			(void) signal(SIGINT, isave);
			(void) signal(SIGHUP, hsave);
		}

Here we want the child process to always recieve interrupts and hangups,
but wish to disable them in the parent. Given the OS9 fork() this would
not be possible. Also in this example we use SIGCLD because we have some
asynchronously running children that are concurrent to this child.


    Steve Blasingame (Oklahoma City)
    ihnp4!occrsh!gorgo!bsteve
    bsteve@eris.berkeley.edu