Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!cmcl2!rna!kc
From: kc@rna.UUCP (Kaare Christian)
Newsgroups: comp.sys.ibm.pc
Subject: Re: OS/2 vs AmigaDOS, 1.4wish, and
Summary: Fork overhead
Message-ID: <593@rna.UUCP>
Date: 22 May 89 15:12:07 GMT
References: <2968@cps3xx.UUCP> <75800069@p.cs.uiuc.edu> <2332@water.waterloo.edu>
Organization: Rockefeller University - Neurobiology
Lines: 92

In article <2332@water.waterloo.edu>, cgeisler@water.waterloo.edu (Craig Eisler) writes:
> 
> To all those who think OS/2 is "missing" something by not having
> (gag puke retch) fork, I say this:
> 
> *pppppppffffffffffftttttttttttttt*
> 
> On a more mature side, fork is a very BAD way of implementing process creation.
> Why the heck should the child look like the parent?  You want a copy of
> some of the data?  Do an initial Send once the child is created.  Fork is
> the biggest resource waste in existence.  Then again, it's a UNIXism, so
> that isn't a big surprise.
> 

"An initial Send", whatever that is, must dupicate I/O connections,
signal handling and other aspects of the original process' state, in
order for it to be as powerful a mechanism as fork. Shared  data is not
the only issue. In a virtual memory environment, with copy on write
being a standard aspect of most shared objects, a fork can be a low
cost operation. (True, way back when, you really had to make a copy.
Today you make a new proc table entry.) Forks make it easy to have
pipes (cheapo, flexible ipc), they make it easy for things like the
shell (or any interactive process) to wait in the background for their
offspring to finish, without mucking up the state (I/O position,
control modes) of the shared I/O connections.

Unix is still the only system that allows most programs to work together
easily, using ad hoc connections. Fork is an essential part of that
flexibility.

Fork's omission from OS/2 is more a reflection of OS/2 trying to be
unlike UNIX, than a reflection that fork itself is bad.

(This is not to say that OS/2 threads are bad. It is nice to have a range of
choices.)

And now a few numbers. How fast is "fast enough" for fork? The simple
program shown below produced the following numbers on the following
machines/configurations.

uVAXii     BSD/XINU 4.3  15ms/fork
Sun 3/260  OS 4.01       35ms/fork
Sun 3/50   OS 4.01       65ms/fork

Now 35 ms *is* a long time, but it seems to me that you are getting a
lot for those milliseconds. For example, if I were to set up a 'grep |
awk | sed | pr' sort of pipeline, the fork overhead there would be
something like 140 ms (on the 260), which is pretty trivial compared
to the time spent exec'ing, processing, reading files, passing data
in pipes, etc. *AND*, the pipeline mentioned above is ad hoc, the
designers of the individual programs didn't have to plan ahead for it.
Thread techniques won't, I suspect, be so flexible.

And now for the source:

/* time forks */
#include <sys/types.h>
#include <sys/wait.h>

#define NFORKS 1000

main()
{
	time_t start, finish;	/* times */
	int firstpid, lastpid;	/* pids */
	int i;
	
	time(&start);
	if (!(firstpid = fork()))
		exit(0);
	else
		wait((union wait *)0);
	for(i=0;i<(NFORKS-2);i++)
		if (!fork())
			exit(0);
	else
		wait((union wait *)0);
	if (!(lastpid = fork()))
		exit(0);
	else
		wait((union wait *)0);
	time(&finish);
	if (finish == start)	/* don't divide by zero below */
		finish++;
	printf("Forks: first child pid %d, last child pid %d\n",
		firstpid, lastpid);
	printf("%ld secs for %d fork system calls. (%g sec/call)\n",
		finish-start, NFORKS, (double)(finish-start)/(double)NFORKS);
}

Kaare Christian
kc@rna.rockefeller.edu