Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!camex!sunfs3!kent
From: kent@sunfs3.Camex.COM (Kent Borg)
Newsgroups: comp.sys.mac.system
Subject: Re: UNIX limits (was Re: All about sys 7.0 <long>)
Message-ID: <1897@camex.COM>
Date: 29 Mar 91 19:20:23 GMT
References: <1991Mar26.153602.276@ux1.cso.uiuc.edu> <1991Mar27.194158.3258@waikato.ac.nz> <1991Mar27.144323.21504@ux1.cso.uiuc.edu>
Sender: news@Camex.COM
Organization: Camex Inc., Boston MA
Lines: 23

In article <1991Mar27.144323.21504@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes:
>I also think it's important that the limit is per process; much, much less
>restrictive than the mac's 'all processes' limit.  As an application
>writer, I can know that, if I stay within my 20 fd limit, everything
>is peachy.  On the mac, I *ought* to worry about leaving some of those
>precious fd's for other processes (some things, notably the MPW linker,
>don't bother with such niceties).

I think that under 7.0 file control blocks are dynamically allocated
by the system.  I m sure there is still an upper limit, but it is
likely memory capacity/heap fragmentation bound.

If this is true, I like it better than either Unix's or 6.0's
approach.

(Do you really want to edit the source and rebuild your kernel to give
a program more file control blocks?  Somehow I don't think that Unix
is going to be an important shrink-wrap market anytime soon.)

--
Kent Borg                            internet: kent@camex.com   AOL: kent borg
                                            H:(617) 776-6899  W:(617) 426-3577
"We foolishly did not realize that he was stupid."  - April Glasbie 3-20-91