Menu
▾
▴
[Tcl-bugs] [ tktoolkit-Bugs-923174 ] Can't catch loss of X server displaying slave toplevel
|
From: SourceForge.net <no...@so...> - 2005-12-01 07:44:22
|
Bugs item #923174, was opened at 2004-03-25 07:08 Message generated for change (Comment added) made by hobbs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=923174&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 67. Unix Window Operations Group: obsolete: 8.3.4 Status: Open Resolution: None >Priority: 4 Submitted By: John Seal (johnseal) Assigned to: Joe English (jenglish) Summary: Can't catch loss of X server displaying slave toplevel Initial Comment: If a Tcl app on one host is displaying a slave toplevel on another host, and the remote host logs out (thus yanking the X server out from under the window), then the Tcl app dies with XIO error 131 (Connection reset by peer). Any WM_DELETE_WINDOW protocol or <Configure> binding on the window does not fire. There does not seem to be any way in Tcl to catch and handle this event. I happened to be using ActiveTcl 8.3.4.1, but I think it's an intrinisic Xlib problem that would affect any version. This was discussed on c.l.t and in the Tcl chatroom. ---------------------------------------------------------------------- >Comment By: Jeffrey Hobbs (hobbs) Date: 2005-11-30 23:44 Message: Logged In: YES user_id=72656 Is WM_SAVE_YOURSELF something the user can use here? ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2004-03-25 08:14 Message: Logged In: YES user_id=68433 Notes: The root cause of the problem is that XSetFatalErrorHandler is Broken As Designed: the fatal error handler (which is called when the server connection is closed unexpectedly) is not allowed to return; and if it does, Xlib exit()s anyway. It *might* be possible to detect the loss of the server connection in the notifier prior to calling XNextEvent. Need to investigate further how to clean up the resources associated with the display if this occurs. I suspect it will be extraordinarily tricky, due to the complexity of Tk's shutdown logic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=923174&group_id=12997 |