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 editand 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.