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