Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: Is there a limit to create sockets on UNIX??
Message-ID: <3823@auspex.auspex.com>
Date: 5 Aug 90 01:07:37 GMT
References: <8307@pitt.UUCP>
Organization: Auspex Systems, Santa Clara
Lines: 45

>The per-process open file table is one that must be static, given the
>necessary constraint of maintaining a fixed size u area (the area of 
>user memory the kernel keeps to manage per-process data, such as open
>files and sockets).

And given the assumption that the open file table resides entirely in the
U area.  This assumption is not true in SunOS 4.1, for example; the
first 64 entries live there, the rest, if there are any, are, well,
"controlled by tables that live in memory that can be much more flexibly
controlled."

That memory isn't paged or swapped, but I don't know that u areas are
paged or swapped, either in all UNIX systems, and even if they are, if
few enough processes use more than the number of descriptors that can
fit in the U area, the memory cost of wired-down open file tables for
those processes may not be too bad.

>Btw, I believe, but do not know, that Apollo's DomainOS has scalability
>in the number of per-process open files.  DomainOS is built on an
>internally-developed, production-oriented operating system base.  It
>avoids many scalability problems common in traditional UNIX designs.

Domain/OS may implement the open file table in userland; that means it
may "live in memory that can be much more flexibly controlled."

The problem with traditional UNIX systems here is that they haven't been
as hospitable to sharing data structures between processes as other
systems, perhaps due, in part, to less-ambitious original design goals,
and perhaps due, in part, to the PDP-11s small number of large memory
managment chunks; in general, shared stuff has lived in the kernel. 

UNIX systems these days live on hardware a bit more hospitable to
sharing multiple independent pieces of a process's address space, and
mechanisms to allow that sort of sharing are appearing in more UNIX
systems.  Mach's user-mode implementation of the UNIX programmer's
interface may already use Mach's mechanisms of that sort to manage file
descriptors (the USENIX paper leads me to infer that, but it doesn't
come out and say it, at least not from my quick 2-minute scan).

Aegis/DomainOS also lives on hardware of that sort, and happenes to be
designed to use it in that fashion.  Whether this makes it more
"production-oriented" is another matter, and one I'd leave up to people
who can indicate how reliable, etc.  Domain/OS systems they used were as
compared to whatever "conventional UNIX" systems they were using; you'll
probably find people in both camps....