[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

1238.0. "SET IO ERROR HANDLER" by ACESMK::ALEXANDER () Mon Aug 07 1989 13:13

    My customer is using X EVENTS to maintain information on several
    workstations, using a single client to handle all servers on
    the workstations.  He has written his own routine to handle fatal
    errors. When he loses the connection between a single server
    and the client, the client exits, resulting in the termination of
    all the other servers.  
    
    The documentation description on SET IO ERROR HANDLER 
    (p 4-55, Vol 2B, VMS DECwindows Programming) states:
    
    "SET IO ERROR HANDLER specifies a user-written error handler 
     to be called by Xlib if any type of system-call error, such as
     losing the connection to the server occurs.  This is assumed to
     be a fatal condition; the error handler should not return.  If
     the IO error handler does return, the client process exits."
              
    Is there any way around this?
    
    Thanks,
    
    Maggie

T.R	Title	User	Personal Name	Date	Lines
1238.1		STAR::ORGOVAN	Vince Orgovan	`Mon Aug 07 1989 18:49`	7
	On VMS it should be possible to unwind the call stack to continue processing the other client connections. You should not attempt to call back into Xlib using the display ID of the aborted connection, but it should be fine to call Xlib with the remaining display IDs. Note that this isn't really robust in the sense that memory will surely be lost when you unwind the stack.
1238.2		VWSENG::KLEINSORGE	XUIS or DIE.	`Tue Aug 08 1989 13:29`	9
	Vince, Is this guaranteed never to change for VMS? It would be nice to be able to do this... it would even be better if there were a way to clean up. _Fred
1238.3		ULTRA::WRAY	John Wray, Secure Systems Development	`Tue Aug 08 1989 15:25`	5
	It'd be even better if there were a toolkit-supported way to continue after a display disconnection, and (as Fred says) to instruct the toolkit to clean up the mess. That way our Ultrix users would be able to build robust applications too.
1238.4		VWSENG::KLEINSORGE	XUIS or DIE.	`Tue Aug 08 1989 17:30`	6
	The toolkit would be nice, but Xlib would be fine. When I can easily intermix the toolkit and AST events... then it will matter.
1238.5	Thanks	ACESMK::ALEXANDER		`Wed Aug 09 1989 13:45`	9
	From the dialogue, I gather that my customer is out of luck, since fooling around with the stack is not acceptably robust. I'll pursue using the multicast feature in DECnet to solve this. Thanks for the response. Maggie
1238.6	But the problem won't just go away...	IO::MCCARTNEY	James T. McCartney III - DTN 381-2244 ZK02-2/N24	`Thu Aug 10 1989 18:42`	15
	Unfortunately we have this problem as well. DECforms is multi-threaded internally and can control several sessions on multiple displays and terminals concurrently. It will be really nasty if a single XIO error causes an ACMS/CP process (controlling 30 or so workstations and terminals) to crash. Our TP customers have gotten used to the fact that one terminal failing just causes the CP to clean up the session and continue. Is this lack of user specified XIO error handler, percieved as a serious problem? It seriously impacts our ability to provide a robust reliable TP product. James
1238.7		ULTRA::WRAY	John Wray, Secure Systems Development	`Fri Aug 11 1989 12:00`	6
	I sometimes get the impression that robustness in general is a specific non-goal of the X toolkit (and the X protocol, come to that - see the discussion in 60.*). But then I'm a cynic by nature.... John