home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / sgi / graphics / 187 < prev    next >
Encoding:
Text File  |  1993-01-23  |  4.4 KB  |  141 lines
  1. Newsgroups: comp.sys.sgi.graphics
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!ux1.cso.uiuc.edu!cs.uiuc.edu!vela!sglanger
  3. From: sglanger@vela.acs.oakland.edu (LANGER STEVEN C)
  4. Subject: Re: XtAppAddTimeOut woes
  5. Message-ID: <1993Jan22.211151.15159@vela.acs.oakland.edu>
  6. Organization: Oakland University, Rochester MI.
  7. References: <1993Jan22.153634.7388@vela.acs.oakland.edu>
  8. Distribution: na
  9. Date: Fri, 22 Jan 1993 21:11:51 GMT
  10. Lines: 129
  11.  
  12. Hi netters;
  13.  
  14.   This is a vexing problem which, although I have a workaround, bothers
  15. me. I have a Motif app which launches 2 non-graphical children for
  16. data acquisition and device control. The acquisition child sends data
  17. to the parent X-app every N seconds. The parents displays are updated
  18. via a call to XtAppAddTimeeout on a different schedule and ...
  19. Well since a pic is worth 1000 words
  20.  
  21. ----------------------------------------------------------------------
  22. |   Parent MainWin
  23. ----------------------------------------------------------------------------
  24. |
  25. |
  26. |
  27. |                    ----------------------
  28. |    ----------------        |History        |
  29. |    |BarGraph    |         |            |
  30. |    |        |        |            |
  31. |    ----------------        ------------------------
  32. |    
  33. |    
  34. |
  35. |    clock 1        clock 2        clock 3
  36. ------------------------------------------------------------------
  37.  
  38. so the relevant portion of the main's I/O stuff look lik this
  39.  
  40.     XtAppAddInput (contxt, mask, data_child, NULL);
  41.     XtAppAddInput (contxt, mask, device_child, NULL);
  42.  
  43.     XtAppAddTimeOut (contxt, 10000, UpdateDisplays, NULL);
  44.     XtAppAddTimeOut (contxt, 1000, UpdateClocks, NULL);
  45.  
  46.     XtRealizeWidget (toplevel);
  47.     XtAppMainLoop (contxt);
  48.  
  49. You'll notice that the displays are updated about every 10 seconds
  50. (accuracy is not critical). The clocks shouls be updated every second.
  51. Now, here's the rub. Everyting used to work fine untill I added the
  52. clock update function. I could:
  53.  
  54.     1. send/recieve data to the data child
  55.     2. send/recieve data to the device controller child
  56.     3. update my display on schedule
  57.     4. Handle user initiated new graph displays from menu pulldowns
  58.  
  59. After adding the clock updates;
  60.     1. Core dump whenever clock update and display update occured
  61.        nearly at the same time
  62.  
  63. I added the following flag to the clock and display functions
  64.  
  65.     void UpdateDisplays (void)
  66.     {
  67.         if (FLAG ==TRUE) return;
  68.         FLAG = TRUE;
  69.         /*
  70.         *
  71.         * Update Bar, History, CT image or what ever else the
  72.         * user has put on screen
  73.         *
  74.         */
  75.         FLAG = FALSE;
  76.     }
  77.  
  78.     void UpdateClocks (void)
  79.     {
  80.         if (FLAG ==TRUE) return;
  81.         FLAG = TRUE;
  82.         /*
  83.         * update clock 1,2,3
  84.         */
  85.         FLAG = FALSE;
  86.     }
  87.  
  88. This avoided core dumps untill the user made a menu selection that
  89. launched a new graphical display. Then the core dumps continued
  90. IF the new display was being created near a UpdateDisplay and 
  91. clock update (recall clocks are updated every second). So I put
  92. the FLAG check into each and everyone of the Display Creation and
  93. Draw routines. This seems to have stopped the problem for now.
  94.  
  95. QUESTION:
  96.     The core dumps all occured at  XtAppMainLoop.
  97. dbx reveals that the fatal error is within
  98.  
  99.     XtDispatchEvent (&event);
  100.  
  101. Why should this be? I thought the whole point of  XtAppAddTimeout
  102. was that it checks for events in the queue, AND DOES NOT INVOKE 
  103. new Xlib calls if some are already pending. And everything used
  104. to work untill I added the clock updates every second. The 
  105. FLAG scheme seems to work, but this is annoying.
  106.  
  107. ANy suggestions on a cleaner way to beat this?
  108.  
  109. best regards, steve
  110.  
  111.  
  112.  
  113. *******************************************************************
  114. Followup. It seems that I was lulled into a false sense of
  115. security. The blow ups have resumed and my FLAG seems to have been
  116. a red herring. dbx reports
  117.  
  118. 0 _XmFindTopMostShell
  119. 1 _XmCallFocusMoved
  120. 2 _XmTrackShellFocus
  121. 3 DispatchEvent
  122. 4 DecideToDispatch
  123. 5 XtDispatchEvent
  124. 6 XtAppMainLoop
  125.  
  126. DOes this mean anything to the Xperts?
  127.  
  128.  
  129.  
  130. -- 
  131. Steve Langer                     sglanger@argo.acs.oakland.edu (VMS)
  132. Oakland University               sglanger@vela.acs.oakland.edu (Ultrix)
  133. ---------------------------------------------------------------------------
  134. Standard disclaimers apply. In addition, the author makes no guarantees,
  135. concerning the grammatical accuracy of his writing. Therefore, any ^B's, ^C's, 
  136. midword character additions/deletions and other non-sense which occurs (after 
  137. the work leaves the author's decade old text editor via his decade old Amiga, 
  138. struggles through a local 1200 baud Merit server to be further mauled via the 
  139. remote VAX mail servers) is someone elses problem - namely yours.
  140. ---------------------------------------------------------------------------
  141.