[comp.windows.x] Summary: XSun server

brossard%litsun.epfl.ch@MITVMA.MIT.EDU (Alain Brossard) (11/11/89)

                [Sent: Sat. 11/Nov./89  Time: 13:49]
        Here is a summary of the replies I had concerning my problem which
was that I could only open a limited number of connections to the server.

From: Bob Sutterfield <bob@archer.morningstar.com>
    Edit /usr/include/sys/param.h and change the value of NOFILE, and
    recompile your kernel from sources.  Then your X server should be able
    to display more windows, which are related to client connections, each
    of which counts against the X server process' open file descriptor
    budget.
(already at max for SunOS3.5, so no solution here (but probably right problem))

From dinah@nicolle.bcm.tmc.edu Wed Nov  8 19:08:01 1989
    I run into this problem frequently on my xterminal which has its own
    internal memory. I believe in my case it is a problem with running out of
    memory. On a workstation, it could be related to swap space.
( In our case there is no problem with memory. )

From mouse@larry.mcrcim.mcgill.edu Thu Nov  9 08:59:17 1989
        (full copy was posted)
    What is almost certainly happening is that the X server is running out
    of file descriptors.  Its limit is 20; subtract 3 for stdin, stdout,
    and stderr, and you get 17.

    Under release 3.5, you can't do anything about this unless you have
    kernel source(...)
(Looks like he is right since we have already (see below) bumped the
limit to the maximum)

From casper@fwi.uva.nl Thu Nov  9 11:51:36 1989
    Three things could be happening:

    a) The per process file table has overflown. This seems unlikely because
    on sun systems NOFILE is 64. Each X-client requires only one fd at the
    server. This would allow you to have some 60 clients.
(BTW NOFILE is max 30 (or 31) under SunOS 3.5)
    b) The system wide table of open files has overflown (nfile). (param.c)
(definitely not the case)
    c) The system wide table of used inodes has overflown (ninode). (param.c)
(not the case either)
    Bumping up MAXUSERS in the kernel should help.
    I think you will need at least 8.
(We have 16 on SunOS4.0)

From david@ics.com Fri Nov 10 08:04:16 1989
    We hit the wall at 18 top-level connections on a Sun 3/160 SunOS 4.0.1
    and 16 on a Sun 3/50, 3.5.  I spent quite a bit of time hacking around
    and annoying Sun support. The best they were able to tell me was to
    fiddle with the NFILES or MAXUSERS values, which did nothing.
    We still have no resolution on the problem.


        Well, I kind of fixed the problem by recompiling the Xserver under
4.0.1 with a NOFILE of 64 and MAXUSERS of 16.  Without recompiling our
kernel under 3.5 (we still have 2 machines that use it), I can't assert
that we already have NOFILE to the maximum (30 or 31) for those machines but
that is what our include files say.  I tend to agree with der Mouse that
under 3.5 there isn't much hope for improvement.  I might also had that
running an Xserver compiled on a 3.5 machines, but running on 4.0. also
suffers from the limitation of our 3.5 systems.  (Sorry, but that wasn't
obvious to me).
        As an aside, X recompiled "fine (sort of)" under 3.5 with gcc 1.35,
but I had to use cc on 4.0 because the server wouldn't respond if compiled
with gcc.  BTW, gcc itself was compiled under 3.5 so ...  (Grrr can't wait
for all our machines to be running the same OS).


        So thanks to all those who replied,

                                                Alain Brossard
                                                brossard@litsun.epfl.ch

PS      I fervently hope that R4 will be out before christmas because I'm
going back to Canada and hope to snatch a copy (hard to do from Switzerland:(
hint hint...