From: sglanger@vela.acs.oakland.edu (LANGER STEVEN C)
Subject: Re: XtAppAddTimeOut woes
Organization: Oakland University, Rochester MI.
Distribution: na
Date: Fri, 22 Jan 1993 21:11:51 GMT

Hi netters;

  This is a vexing problem which, although I have a workaround, bothers
me. I have a Motif app which launches 2 non-graphical children for
data acquisition and device control. The acquisition child sends data
to the parent X-app every N seconds. The parents displays are updated
via a call to XtAppAddTimeeout on a different schedule and ...
Well since a pic is worth 1000 words

----------------------------------------------------------------------
|   Parent MainWin
----------------------------------------------------------------------------
|
|
|
|					----------------------
|	----------------		|History		|
|	|BarGraph	| 		|			|
|	|		|		|			|
|	----------------		------------------------
|	
|	
|
|	clock 1		clock 2		clock 3
------------------------------------------------------------------

so the relevant portion of the main's I/O stuff look lik this

	XtAppAddInput (contxt, mask, data_child, NULL);
	XtAppAddInput (contxt, mask, device_child, NULL);

	XtAppAddTimeOut (contxt, 10000, UpdateDisplays, NULL);
	XtAppAddTimeOut (contxt, 1000, UpdateClocks, NULL);

	XtRealizeWidget (toplevel);
	XtAppMainLoop (contxt);

You'll notice that the displays are updated about every 10 seconds
(accuracy is not critical). The clocks shouls be updated every second.
Now, here's the rub. Everyting used to work fine untill I added the
clock update function. I could:

	1. send/recieve data to the data child
	2. send/recieve data to the device controller child
	3. update my display on schedule
	4. Handle user initiated new graph displays from menu pulldowns

After adding the clock updates;
	1. Core dump whenever clock update and display update occured
	   nearly at the same time

I added the following flag to the clock and display functions

	void UpdateDisplays (void)
	{
		if (FLAG ==TRUE) return;
		FLAG = TRUE;
		/*
		*
		* Update Bar, History, CT image or what ever else the
		* user has put on screen
		*
		*/
		FLAG = FALSE;
	}

	void UpdateClocks (void)
	{
		if (FLAG ==TRUE) return;
		FLAG = TRUE;
		/*
		* update clock 1,2,3
		*/
		FLAG = FALSE;
	}

This avoided core dumps untill the user made a menu selection that
launched a new graphical display. Then the core dumps continued
IF the new display was being created near a UpdateDisplay and 
clock update (recall clocks are updated every second). So I put
the FLAG check into each and everyone of the Display Creation and
Draw routines. This seems to have stopped the problem for now.

QUESTION:
	The core dumps all occured at  XtAppMainLoop.
dbx reveals that the fatal error is within

	XtDispatchEvent (&event);

Why should this be? I thought the whole point of  XtAppAddTimeout
was that it checks for events in the queue, AND DOES NOT INVOKE 
new Xlib calls if some are already pending. And everything used
to work untill I added the clock updates every second. The 
FLAG scheme seems to work, but this is annoying.

ANy suggestions on a cleaner way to beat this?

best regards, steve



*******************************************************************
Followup. It seems that I was lulled into a false sense of
security. The blow ups have resumed and my FLAG seems to have been
a red herring. dbx reports

0 _XmFindTopMostShell
1 _XmCallFocusMoved
2 _XmTrackShellFocus
3 DispatchEvent
4 DecideToDispatch
5 XtDispatchEvent
6 XtAppMainLoop

DOes this mean anything to the Xperts?



-- 
Steve Langer  			       sglanger@argo.acs.oakland.edu (VMS)
Oakland University		       sglanger@vela.acs.oakland.edu (Ultrix)
---------------------------------------------------------------------------
Standard disclaimers apply. In addition, the author makes no guarantees,
concerning the grammatical accuracy of his writing. Therefore, any ^B's, ^C's, 
midword character additions/deletions and other non-sense which occurs (after 
the work leaves the author's decade old text editor via his decade old Amiga, 
struggles through a local 1200 baud Merit server to be further mauled via the 
remote VAX mail servers) is someone elses problem - namely yours.
---------------------------------------------------------------------------