Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.windows.x
Subject: Re: Maximum number of XOpenDisplay() allowed by a client.
Keywords: XOpenDisplay, X11R3
Message-ID: <2974@auspex.auspex.com>
Date: 26 Feb 90 23:29:24 GMT
References: <3002@soleil.oakhill.UUCP> <2860@bacchus.dec.com> <3015@soleil.oakhill.UUCP>
Organization: Auspex Systems, Santa Clara
Lines: 83

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