Conference bulova::decw_jan-89_to_nov-90

  I've seen this error after about 16 XOpenDisplay calls were made from a
single application.  I wrote a small program to determine how many display
connections a server could handle and after about 16 this message showed up.

  I then wrote the program to open a display connection and then loop forever
and ran several of these programs.  This was all done under VMS and with the
_single connection_ programs I could account for all 32 connections (max with
VMS).  So I concluded that this error only occurs if so many connections are
made from a single processes.

  At the time I did this I contacted TBU but we couldn't ever get an answer
to this particular error message.

  This was done with VMS V5.3 on a VS3520.  The same result occured with
either LOCAL or DECNET transports.

  Hope this offers a little insight...

					-=> Jim <=-

There are two circumstances where NOMORE is used (I just found via a source
search).  One is if you do an XOpenDisplay more than 20 times (without a longer
look, I'm not sure if this is simultaneously or if 20 open/close pairs will do
it).  This number comes from _NFILE in the CRTL (the number of simultaneous file
opens a process can have, in theory, but I think in practice, a hack in the
CRTL to simulate the UNIX function).

The other is that in the VAX bindings, lists of things (for example fonts,
extension names, etc) are gotten by repeated calling of a routine which returns
one at a time.  X$_NOMORE is the status returned when there are no more values
to return.  It should not be signaled, but the calling program might have done
that.

Burns

I ,too, have the message when I call 22th XOpenDisplay on V5.3 system!!
(I don't have on V5.2 system ... )
Thanks a lot, Jim and Burns.

But I don't know why the number of XopenDisplay calls is limited.
Do you know anything ?


								AIKO

    
    Have a look in notes 2438.*
    
    An answer on how many open display is in it.
    
    				Jean-claude.
    

Re .2: This doesn't sound like a reasonable error message for "too many
display opens"...

	paul

re .4:  The limit listed in 2438 is the number of simultaneous clients that
a server can have connected.  The question in this note is how many displays
a single process can have.

The reason for the limit is that a favorite Unix trick is the dimension an
array to size _NFILES (the number of files which can be open by a process
simultaneously) and to then index the array by a file descriptor ( a number
between 0 and _NFILES-1.).  It turns out that this is the only way that one
can reliably implement an extension in xlib.  While _NFILES is not really the
VMS limit for the number of files a process can have open, it is supplied by
the CRTL so that people can continue to use the same trick.

In order for this to work, Xlib has to stick a unique number between 0 and
_NFILES-1 into dpy->fd.  In order to do this the maximum number of connections
that we can have are _NFILES.

Now, you ask, why can't _NFILES be bigger?  Good question.  Ask the CRTL folks.

As to the message:  I expect you are right.  Please qar it.

Burns

Does anyone know if this was ever actually QAR'd, and if
so the QAR number and/or an idea what version of 
DECwindows/VMS it will be "fixed" in?

It is quite likely that this will turn into a CLD for a 
customer.  Any information will be appreciated.


Thanks,

Ken
Colorado CSC

    
    
    	It hasn't been QAR'ed, but I'll create one.  I expect the fix will
    be in DECwindows V3.
    
    	Sam