MAX FILES PER PROCESS PROBLEM - (nf)

[ron%b...@sri-unix.uucp]

From: Ron Natalie <ron@brl-vgr>

Actually, the classic sorter an IBM 82 had 13 bins. One for each card
row plus a reject bin, two knobs, and some buttons. If this were an
IBM and we were using EBCDIC we could actually simulate the kind of sort
they were doing.

-Ron Natalie
(Born in 1959, not too late to use punch cards without the benefit
of a computer.)

[edhall%r...@sri-unix.uucp]

Yes, the classic IBM sorter I used had 13 bins, as you described.

I stand corrected; my memory must be deteriorating with age. :-)

I think the issue of limitations to various UNIX features, as
distinguished from the *lack* of features, is an interesting one.
I find UNIX to be relatively free of unreasonable restrictions
(at least the Berkeley virtual-memory versions).

-Ed

[dm%bb...@sri-unix.uucp]

From: Dave Mankins <dm@bbn-unix>

Sorting aside, there are legitimate uses for allowing more than
20 open files to a process. Our original implementation of TCP
(on an 11/70 running a modified version 6 UNIX many years ago)
was written as a user-mode program which was the only process
allowed to talk to the network device (a slight
oversimplification). User programs (e.g., telnet, ftp, the
mailer) would then open up RAND ports (which are similar to
"named pipes") to talk with the TCP program, which, in turn
controlled communications with the network. Limiting a process
to 20 open files means you can have only about 8 processes using
the network (network connections each take two files, one in each
direction, and it's nice to have a logging output file as well).

TCP is a large, complicated protocol, and is somewhat difficult
to fit into an 11's kernel space without coming up with an
overlay scheme (although I understand that someone at MIT has
succeeded in doing so). It would also be nice if the kernel didn't
take up the entire memory of a small 11, and putting TCP in user
mode meant it could be swapped once in a while.

This was before there were VAXes, of course.

[lwa%m...@sri-unix.uucp]

Well, actually our TCP implementation here at MIT mostly runs
in user processes. The kernel contains those pieces of the
protocols necessary for demultiplexing incoming packets out
to user processes; each user process contains the rest of
the protocol layers (for example, Internet, TCP, and user Telnet).
-Larry Allen
-------

[edhall%r...@sri-unix.uucp]

> ... This may
> be familiar to you if you've ever sorted on a card sorting machine (most of
> the net is probably too young to have had that particular experience).

Well, sonny, it sure is nice to know that most people on the net are
younger than my ripe old age of 29. (:-)) However, I seem to remember
the card-sorting machine I used having only 10 stacks, not 26. A limit
of twenty open files is generous by those standards! (And, yes, there
were techniques of doing alphabetic sorts on this card sorter. This
required two passes per column, though.)

Here in the real world we constantly have to make compromises based on
physical constraints. Perhaps the `real world' of computing is so
flexible that *any* constraint seems fair game for removal. But I
hardly consider the 20- (or 32-) file limit to be holding back progress
in the same manner as, say, a 16-bit address.

Have no fear, however! Note that the 4.2 features which use bit
strings (such as select()) use a *pointer* to integer, leaving open
the possibility of an arbitrary number of bits for such things, and
not a maximum of the magic `32'.

-Ed Hall
edhall@rand-unix (ARPA)
decvax!randvax!edhall (UUCP)