lkw@csun.edu (Larry Wake) (12/01/88)
In article <193@utacfd.UUCP>, Pnews swears rwn@utacfd.UUCP (Ralph Noack) wrote: >There are no limits on the number of open windows other than >the swap. When Steve Jobs and Co. did their show for the CSU, 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. He said there was a maximum of 256 windows. I didn't get a chance to find out whether that meant top-level windows or some other abstraction. He felt that 256 was more than any human being would ever need, which I tend to question, especially given examples such as the dictionary popping up two windows for every entry in a search that covered scads of definitions. So, what's the real answer? Did the person doing the demo in Texas think 256 == "no limit", or was the person in California misinformed, or was it a matter of two different questions being answered? -- Larry Wake lkw@csun.edu CSUN Computer Center uucp: {hplabs,rdlvax}!csun!lkw Mail Drop CCAD BITnet: LKW@CALSTATE Northridge, CA 91330
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (12/02/88)
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 <sys/param.h> 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.
geoff@desint.UUCP (Geoff Kuenning) (12/02/88)
In article <28876@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: > 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... I bet I'm not the only one who's going to jump on this, but just in case... Don't confuse X *clients* with X *windows*. NOFILE indeed limits the number of clients you can have. However, each client can open an effectively unlimited (i.e., limited by other resources such as memory) number of windows. An X server running 15 clients probably has 20 to 100 windows open, depending on the clients and on the window manager being used. -- Geoff Kuenning geoff@ITcorp.com uunet!desint!geoff
mao@blia.BLI.COM (Mike Olson) (12/03/88)
bob@allosaur writes: > 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 ... this isn't strictly next-related, so i'll keep it brief (followups to comp.windows.x) -- the number of open *windows* is distinct from the number of *clients*. a single client (program) may open as many as it wants; as a test, i just opened four thousand on a sun 3/60 running sunOS 3.4. mike olson britton lee, inc. ...!ucbvax!mtxinu!blia!mao mao@blia.BLI.COM
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (12/03/88)
In article <1813@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: |In article <28876@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: |>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... | |I bet I'm not the only one who's going to jump on this, but just in case... So far you are the only one. Why is everyone being so gentle today? :-) |Don't confuse X *clients* with X *windows*. NOFILE indeed limits the |number of clients you can have. However, each client can open an |effectively unlimited (i.e., limited by other resources such as |memory) number of windows. You're right - I was imprecise. Perhaps my memory was clouded by the fact that there weren't many multi-window clients under X10, which is what we used in the pre-3.4 period.
davidh@dent.Berkeley.EDU (David S. Harrison) (12/03/88)
> 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. Small correction: one could only have 14 *client applications* connected to the server at once. Under X, each client can create as many windows as it likes subject to the memory constraints of the server. David Harrison UC Berkeley Electronics Research Lab (davidh@ic.Berkely.EDU, ...!ucbvax!davidh)