[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

2945.0. "Repeated open / close display on VMS v5.3(+)" by COMICS::BELL (Soldier of the Line) Mon Jun 18 1990 07:03

      Are there any reported problems with repeated open/close displays
    with a DECwindows v2 client ?

      When the attached program [ simple loop of open display then close
    display ] is run on a VMS v5.3+ client then it fails on about the 113th
    iteration (may vary between systems but remains constant across repeated
    runs). When it is run on a VMS v5.1 client it completes as many as you
    ask for (over 300 when testing).

      The version of the server made no difference (same result to v5.1 
    as to v5.3-1) and the transport only changed the critical limit by
    one during testing.

      The attached program uses the MIT C binding but this has also been
    duplicated using the VMS binding from Fortran.

      Any ideas ? Thanks in advance for all information, pointers, etc..

      Frank

/*---------------------------------------------------------------------------*/
/* MIT C version of LOOP.FOR (Open/close display fails after n iterations).  */
/*---------------------------------------------------------------------------*/

#include "decw$include:xlib.h"

Display *dpy ;                                                 /* Display id */
int     loop ;                                                    /* Counter */
int     limit ;                                               /* No of loops */

main()
{
  printf("Enter number of loops to attempt [int] : ") ;
  scanf("%d", &limit) ;                                     /* Wait for user */

  for (loop=1 ; loop<=limit ; loop++) {            /* Test  simple operation */
    dpy = XOpenDisplay(0) ;                          /* Open another display */
    if (dpy==0) {                                        /* Operation failed */
      printf("Display not opened - loop = %d\n", loop) ;  /* Say when failed */
      sys$exit(1) ;                                           /* Exit tidily */
    }                                           /* .. failed to open display */
    XCloseDisplay(dpy) ;                                   /* Close this one */
  }                                                          /* .. main loop */

  printf("Completed %d open/close display loops\n", limit) ;  /* Inform user */
}

T.R	Title	User	Personal Name	Date	Lines
2945.1		DECWIN::FISHER	Prune Juice: A Warrior's Drink!	`Mon Jun 18 1990 13:26`	7
	There was a similar question recently that I answered in more detail, but the answer is yes...there is a limit (essentially whatever the C library supplies for NFILES) on the number of open displays that you can have. And there is a bug such that it does not recycle the numbers, so open and close has the same effect. Burns
2945.2		COMICS::BELL	Soldier of the Line	`Tue Jun 19 1990 08:47`	19
	Thanks Burns, I checked for relevent titles throughout this file [especially since the beginning of April = "recently"] but haven't found anything. Could you point me to it please ? Where is NFILES defined ? How can I find out what a particular version of C uses for its value [to confirm the problem] ? The only limit I can find is the absolute of 255 [= byte storage] (discounting the ANSI constant FOPEN_MAX [=8]). Using SDA the process doesn't release a channel after the close display so just increases the number of channels, presumably until CHANNELCNT is hit. Is this a symptom of the "not recycling its numbers" bug that you mentioned ? Does the SPR go to VAXCRTL or DECwindows/Xlib ? (ie., is it a C bug that DECwindows has tripped over or is it 100% original material ? :-) Frank
2945.3		DECWIN::FISHER	Prune Juice: A Warrior's Drink!	`Tue Jun 19 1990 13:25`	15
	I'll see if I can find it. _NFILE (note corrected spelling) is defined in stdio.h in sys$library. It is a compile-time constant which, on V5.3-1, is defined to be 20. That is why I was a bit puzzled by the fact that you could get up to several hundred opens. It is an Xlib bug that the number is not recycled. One could argue that it is a feature that only _NFILE displays can be opened at once (since there would be that limit on Unix as well). I suppose one could also argue that _NFILE should be larger in stdio.h, or that it should be run-time defined rather than compile-time and should relate to CHANNELCNT or some such. The problem is then you can't use it to define the size of a static array, which is what most c programs that use it want it for. Burns
2945.4		DECWIN::FISHER	Prune Juice: A Warrior's Drink!	`Tue Jun 19 1990 13:47`	13
	I couldn't find it either. Essentially the problem is that extensions need a method of getting an extension-created display-specific structure quickly. In Unix, you do this by using dpy->fd, the file descriptor, as an index into an array dimensioned to _NFILE, the maximum size of a file descriptor. Pre- V5.3 or so, VMS was using dpy->fd to contain an event flag. Useful to transport, but not to anyone else. This was changed to contain a display-unique index with a max of _NFILE. This is all ok, except for the fact that the number was apparently not reused (if I remember right) after a Display was closed. I still don't understand why you got up into the hundreds. Maybe I am remembering a bit wrong what the problem was. That is why I really wanted to find the note I answered before because I did all the research to get the details. Burns
2945.5	Looks like it's beyond the control of mere mortals ...	COMICS::BELL	Soldier of the Line	`Wed Jun 20 1990 07:19`	22
	Burns, Thanks for all the work you've done. This is now looking like it isn't a problem with recycling the display-unique index - which should stop at _NFILE as you say - but with another section of the code : the bit which should [but doesn't] deassign the channel to WSAnn: during CloseDisplay. The original problem was a simulation of a program intended to run long term without interruption, which would open a display, do it's work, close the display, do some more work, open a display ... etc.. It was found that after a number of cycles, the dpy returned would be null but no error would be flagged. The code in .0 is the minimum that will give the same result ... just skips doing the useful work in between ! OK, as it doesn't look like there's anything to be done at compile or run time, I think the next step is an SPR. Thanks again for your help. Frank [ I don't suppose it depended on the event flag that used to be in dpy->fd ... nah, they wouldn't have ... would they ? :-) :-) ]
2945.6	Do you have more info?	DEVO::FISHER	Prune Juice: A Warrior's Drink!	`Thu Jun 21 1990 11:06`	9
	When you say "the bit which should [but doesn't] deassign the channel to WSAnn: during CloseDisplay", does that imply that you have traced some more stuff down? I would think that WSAnn should not remain open. All that should be done to it is to do a GET CHARACTERISTICS QIO to it to get the node, transport, etc. Perhaps it should be closed right away after that and it is not? Anyway, include all the info you have in the QAR. Burns
2945.7	Not proof but pretty close to it ...	COMICS::BELL	Soldier of the Line	`Wed Jun 27 1990 07:58`	14
	Sorry for the delay ... no I haven't traced the code - haven't got the v2 sources - just used SDA to watch the number of channels assigned to WSAnn increase each time the prog went round the Open/CloseDisplay loop. Hmmm ... just looked at the v1 sources and found an interesting comment in the mod history for the connect display code : "Fix leak that left channel open to WSAn: device" !! [VRO0001] As this problem doesn't occur under v1 but does under v2 it sounds rather like the above deassign was 'lost' or bypassed. Frank