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