Path: utzoo!utgpu!watmath!clyde!att!rutgers!tut.cis.ohio-state.edu!allosaur.cis.ohio-state.edu!bob
From: bob@allosaur.cis.ohio-state.edu (Bob Sutterfield)
Newsgroups: comp.sys.next
Subject: Re: Number of windows?
Keywords: demo, NeXT
Message-ID: <28876@tut.cis.ohio-state.edu>
Date: 1 Dec 88 20:36:05 GMT
References: <193@utacfd.UUCP> <1734@csun.edu>
Sender: news@tut.cis.ohio-state.edu
Organization: The Ohio State University Dept of Computer & Information Science
Lines: 30

In article <1734@csun.edu> lkw@csun.edu (Larry Wake) writes:
>...I asked one of their tech types whether windows were "cheap" a la
>X, or expensive a la SunView 1, where each window is tied to one or
>more file descriptors.

The X server sees each client connection through a socket, which takes
up a file descriptor slot, which counts against NOFILE.  For example,
using an X server compiled before SunOS 3.4, one could only have 14
windows open on the screen because NOFILE was only 15 (a fd was thrown
away for various overhead things).  In SunOS since 3.4 NOFILE is 30.
I don't know about 4.0.

BBN's Butterfly Mach sets NOFILE at 64.  I don't know how NeXT's Mach
treats NOFILE, but it could be a much larger number - like the 256 you
heard.  You can raise it yourself if you have kernel sources - just
edit  and recompile.

But then, you won't be able to do that unless NeXT releases their
kernel sources.

Still, this isn't what's really happening because NeXTStep
applications talk to the server via Mach ports rather than via UNIX-
or internet-domain sockets (and therefore fd's).  The socket interface
is still there for use by remote, non-Mach clients, and those would
absorb some fd's.  I'm not familiar enough with Mach guts to know what
the similar limit might be on port connections to a single process, if
there even is a limit.

Of course, the issue of remote, non-Mach clients is moot unless NeXT
releases the source to their protocol and toolkit libraries.