Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!lll-lcc!lll-tis!ptsfa!hoptoad!academ!killer!jfh
From: jfh@killer.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Determining the max number of open files on System V
Message-ID: <975@killer.UUCP>
Date: Mon, 8-Jun-87 13:38:53 EDT
Article-I.D.: killer.975
Posted: Mon Jun  8 13:38:53 1987
Date-Received: Sat, 13-Jun-87 04:37:46 EDT
References: <7730@brl-adm.ARPA>
Organization: The Unix(tm) Connection, Dallas, Texas
Lines: 24
Summary: No - forks are never _cheap_

In article <7730@brl-adm.ARPA>, bzs@bu-cs.bu.EDU (Barry Shein) writes:
>                                                         I'd recommend
> using a subroutine which forks the job simply because on 4.x you can
> use getdtablesize() so it would be trivial to conditionalize at
> compile-time.
> 
> Remember guys, this is Unix, we keep forks cheap for a reason, why
> reinvent the wheel?
> 
> 	-Barry Shein, Boston University

I was the guy at my last job who benchmarked unix on our system.  I learned
many things from this little experience.  Rule 1:  Fork is as expensive a
system call as you can get.  The only thing more expensive is fork/exec.
Rule 2:  Emulation libraries are easy to write.  Writing getdtablesize()
is worth the effort especially since you can sell it as a 'Berkeley
Enhancement' - or your can always use it yourself when dealing with all of
the code from usenet that uses it.

Don't fork - please.  I believe there are no fewer than 2 forks() per
system(3) call, and a 68000 machine can only handle 30 or so per second,
depending on the size of the module.

- John.