ephrem@oakhill.UUCP (Ephrem Chemaly) (02/23/90)
I have a SUN 3/260 with X11R3 as well as a MacII running A/UX with X11R3. I need to open several displays from one client to send information to other clients on those displays. Naturally I use the XOpenDisplay(DisplayName) to open a new display. This works fine for about 4 displays and then I get an error and the client crashes. Sometimes though I have been able to open as many as 11 displays before I get the error. This happens on both the SUN and the MacII. Is there any limitations on the number of displays a client can open at one time? Thanks in advance. Ephrem A. Chemaly oakhill!soleil!ephrem@cs.utexas.edu (512)891-2760 MOTOROLA Inc. 6501 W. William Cannon Dr. MS OE28 Austin, TX 78735 U.S.A.
klee@wsl.dec.com (Ken Lee) (02/23/90)
In article <3002@soleil.oakhill.UUCP>, ephrem@oakhill.UUCP (Ephrem Chemaly) writes: > Is there any limitations on the number > of displays a client can open at one time? This is implementation and system dependent. On many UNIX-type systems, X uses sockets for client-server communication. Each socket takes up a file descriptor. The number of file descriptors is limited, very limited on some old systems, though you may be able to increase this by reconfiguring your UNIX kernal. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
converse@EXPO.LCS.MIT.EDU (Donna Converse) (02/23/90)
> Is there any limitations on the number > of displays a client can open at one time? What happens when you run this? #include <stdio.h> #include <X11/Xlib.h> main() { int i; Display* dpy; i = 0; dpy = XOpenDisplay(NULL); while (dpy != NULL) { fprintf(stderr, "%i\n", i++); fflush(stderr); dpy = XOpenDisplay(NULL); } exit(0); }
david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) (02/23/90)
In article <9002230051.AA13764@expo.lcs.mit.edu> converse@EXPO.LCS.MIT.EDU (Donna Converse) writes: > >> Is there any limitations on the number >> of displays a client can open at one time? > >What happens when you run this? > > [ program deleted ] . . . 44 45 46 47 48 49 Xlib: connection to "unix:0.0" refused by server Xlib: Maximum number of clients reached Above on X11R4 on a Sun 3/460 running 4.0.3. This can occur because an xalloc failed (the server ran out of memory, should rarely happen), or if too many file descriptors have been opened. For HP machines, this is a #define (_NFILE), for others the max number of descriptors available to a process (i.e., the number of descriptors the server can have open) is obtained by from getdtablesize(2): NAME getdtablesize - get descriptor table size SYNOPSIS nds = getdtablesize() int nds; DESCRIPTION Each process has a fixed size descriptor table, which is guaranteed to have at least 20 slots. The entries in the descriptor table are numbered with small integers starting at 0. The call getdtablesize() returns the size of this table. see mit/server/os/4.2bsd/connection.c
ephrem@oakhill.UUCP (Ephrem Chemaly) (02/23/90)
In article <9002230051.AA13764@expo.lcs.mit.edu>, converse@EXPO.LCS.MIT.EDU (Donna Converse) writes: > > > Is there any limitations on the number > > of displays a client can open at one time? > > What happens when you run this? > > #include <X11/Xlib.h> > #include <stdio.h> > > main() > { > int i; > Display* dpy; > > i = 0; > dpy = XOpenDisplay(NULL); > while (dpy != NULL) { > fprintf(stderr, "%i\n", i++); > fflush(stderr); > dpy = XOpenDisplay(NULL); > } > exit(0); > } After running this program on the SUN I got: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 XIO: fatal IO error 54 (Connection reset by peer) on X server "(null)" after 0 requests (0 known processed) with 0 events remaining. I removed a couple of X clients (xterm in this case) from the display, and I got: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 XIO: fatal IO error 54 (Connection reset by peer) on X server "(null)" after 0 requests (0 known processed) with 0 events remaining. Since I was able to open two additional displays because I removed to clients it sounds that this is a limitation of my UNIX kernel. Also I ran this program on A/UX and the results were similar except the error was: file: table is full This confirms Mr. Ken Lee's (DEC Western Software Laboratory) answer. It sounds like I have to go back and reconfigure my kernel. Thanks for your help Ephrem A. Chemaly oakhill!soleil!ephrem@cs.utexas.edu (512)891-2760 MOTOROLA Inc. 6501 W. William Cannon Dr. MS OE28 Austin, TX 78735 U.S.A.
ephrem@oakhill.UUCP (Ephrem Chemaly) (02/24/90)
In article <2860@bacchus.dec.com>, klee@wsl.dec.com (Ken Lee) writes: > In article <3002@soleil.oakhill.UUCP>, ephrem@oakhill.UUCP (Ephrem > Chemaly) writes: > > Is there any limitations on the number > > of displays a client can open at one time? > > This is implementation and system dependent. On many UNIX-type > systems, X uses sockets for client-server communication. Each socket > takes up a file descriptor. The number of file descriptors is limited, > very limited on some old systems, though you may be able to increase > this by reconfiguring your UNIX kernal. > right after the application crashes I ran $ pstat -T on the SUN 3/260 to print system statistics. I got the following: 168/1888 files 151/634 inodes 51/522 processes 9/ 88 texts 5920/62088 swap It seems that I have enough files descriptors left ( I think, since I am not a UNIX guru). Is this what you were refereing to ken? On the other hand right before I got the error on A/UX, pstat gave me: 100 buffers: 0 busy, 0 wanted, 98 done, 1 nodev 82 out of 100 inodes active 35 out of 50 processes active 95 out of 100 files active It seems that I am getting close to the limits of my system. After I created another client pstat gave me: /unix: no namelist file: table is full Here it seems that I am running out of file descriptors. Is this true? If I try to open yet another client I get from pstat: /dev/kmem: File table overflow Here it seems that I am running out of memory. Are all these conclusion true in the case of A/UX. How about the SUN? Thank Ephrem A. Chemaly oakhill!soleil!ephrem@cs.utexas.edu (512)891-2760 MOTOROLA Inc. 6501 W. William Cannon Dr. MS OE28 Austin, TX 78735 U.S.A.
guy@auspex.auspex.com (Guy Harris) (02/27/90)
>on the SUN 3/260 to print system statistics. I got the following: > >168/1888 files >151/634 inodes > 51/522 processes > 9/ 88 texts >5920/62088 swap > >It seems that I have enough files descriptors left ( I think, since >I am not a UNIX guru). Is this what you were refereing to ken? I tend to doubt it. "File descriptors" refers either to the slots in a per-process array that refer to file table entries, or to the small integers that programs get back from e.g. "open" that are used by "read", "write", etc. as indices into the table of those slots. A process generally has some limit on how many such slots it has; in older UNIXes, this limit is 20 or 30, and it goes up to 64 or more in some later systems. This limit is sometimes difficult to increase, especially if you don't have source, and often even if you do. "File descriptors" refer to "file table entries", which come from a system-wide table - file descriptors in different processes can refer to the same file table entry. "pstat", when reporting on "files", is referring to "file table entries", not "file descriptors". The limit on *those* entries is usually much easier to increase, especially if you don't have source. >On the other hand right before I got the error on A/UX, pstat gave me: > >100 buffers: 0 busy, 0 wanted, 98 done, 1 nodev >82 out of 100 inodes active >35 out of 50 processes active >95 out of 100 files active > >It seems that I am getting close to the limits of my system. >After I created another client pstat gave me: > >/unix: no namelist >file: table is full The "file: table is full" message indicates that you're running out of file table entries, not file descriptors, and the report from "pstat" indicates the same thing.... >Here it seems that I am running out of file descriptors. Is this true? No, you're probably running out of file table entries, and... >If I try to open yet another client I get from pstat: > >/dev/kmem: File table overflow This seems to confirm that - it'd say "Too many open files" if you were running out of file descriptors; "File table overflow" means you've run out of file table entries. >Here it seems that I am running out of memory. No. The fact that it says "/dev/kmem" has nothing whatsoever to do with running out of "memory" in general; it just means that "pstat" tried to open "/dev/kmem" and failed to do so because doing so would require a free file table entry, and there weren't any. So what you want to do under A/UX is to increase the number of file table entries. I've no idea what the configuration parameter you tweak to do that is for A/UX, but unless Unisoft and/or Apple screwed up there should be such a parameter. Note, however, that this *still* won't increase the number of file descriptors any process has, and that limit may be, as indicated, difficult or impossible to change. In other words, increasing the number of file table entries may merely cause your program to run out of file descriptors, instead. >How about the SUN? It sounds like you're not running out of file descriptors, rather than file table entries, on the Sun (not SUN, please, when used to refer to products of Sun Microsystems it's not an acronym). Given that, you're pretty much out of luck, unless you upgrade to a later version of SunOS that supports more file descriptors per process.
hvr@kimba.Sun.COM (Heather Rose) (03/07/90)
Sounds like one person is running SunOS 4.0.x and one is running 3.x. The number of file descriptors available is not currently configurable in SunOS. So, don't bother with the kernel... The function "getdtablesize" will return the number of file descriptors available in SunOS. Regards, Heather