🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.sys.sgi.graphics
2 messages
2 total messages Started by LANGER STEVEN C Fri, 22 Jan 1993 15:36
XtAppAddTimeOut woes
#116
Author: LANGER STEVEN C
Date: Fri, 22 Jan 1993 15:36
111 lines
4211 bytes
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


-- 
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.
---------------------------------------------------------------------------
Re: XtAppAddTimeOut woes
#118
Author: LANGER STEVEN C
Date: Fri, 22 Jan 1993 21:11
129 lines
4695 bytes
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.
---------------------------------------------------------------------------
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads