Path: utzoo!utgpu!water!watmath!clyde!att!ihlpa!ihnp4!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga
Subject: Re: Amiga UNIX
Message-ID: <4112@cbmvax.UUCP>
Date: 26 Jun 88 21:16:29 GMT
References: <1985@uhccux.uhcc.hawaii.edu> <4079@cbmvax.UUCP> <6811@cup.portal.com> <2176@sugar.UUCP>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 19

In article <2176@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>Well, you can't implement enough of UNIX to make it worthwhile, because you
>don't have any way of implementing the "fork()" system call without causing
>a huge performance penalty. Now, people counter that most programs follow
>a fork() with an exec(). I guess most do, but many interesting programs I
>know of do things like "if(fork()) exit();", or "if(fork()) { do something
>strange and bizzarre to file descriptors and signals and maybe even do some
>I/O then exec(); }", or "if(fork()) server(); else client();", and so on.

	All you need to do a fork() is to copy the data/stack segments on
task swaps between those two.  After a fork, you'd probably let the child run
for a while, hoping it will exit, exec, or some such soon.  Otherwise, your
task switches for those two processes will be much slower.  But then again,
Unix doesn't claim to be real-time either.  Luckily, VERY few programs
fork without exec()ing or exit()ing soon thereafter (though they often
muck with fd's, etc first.)

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup