yus@ul.ie (03/13/91)
I write a X program using Xlib to open two displays: Display1 on a local workstation for controlling something and Display2 on a remote workstation for monitoring the window information from Display1. That means the program draws the same information in windows on the two workstations. My problem is: When the Window Manager on the remote workstation uses 'cancel' or 'kill' item to kill the window, it causes Window Manager to send a KillClient request to the server, then the server disconnects the display2. My program doesn't know that the connection has been closed, and it keeps drawing information in remote window. So, the program crushed dwon. Could you tell me how can my program get informed or how can my program fetch a connection-closed message from somewhere when the window was killed by the KillClient request? My e-mail address is : yus@ul.ie Please response to me if you know how to do it. Shank you Shousan Yu Dept. of ECE Univ. of Limerick Ireland
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (03/15/91)
> I write a X program using Xlib to open two displays: [...]. > When the Window Manager on the remote workstation uses 'cancel' or > 'kill' item to kill the window, it causes Window Manager to send a > KillClient request to the server, then the server disconnects the > display2. > My program doesn't know that the connection has been closed, and it > keeps drawing information in remote window. So, the program crushed > dwon. One solution is for your program to ask to participate in the WM_DELETE_WINDOW protocol. In this case, window-manager "please zap this window" operations will normally result in your client getting a message from the WM instead of just seeing the connection drop. However, not all window managers understand this yet, and there are other possible reasons for seeing a broken connection. If you want to trap and recover from broken connections, there currently is no very good way. You can catch them by establishing an I/O error handler; the problem is then what to do when your handler gets called. According to the documentation, if you return, Xlib will cause your process to exit. According to my reading of the MIT source, this is not true, but I get the impression that returning will cause Xlib to get confused. And there is no guarantee it's safe to longjmp() out. I suppose you could fork and have one child deal with each display, thus allowing the child to die without killing off the whole program, but that (a) restricts you to UNIXish systems and (b) seems somewhat excessive. The right solution is to fix Xlib's handling of I/O errors; someday if I have the time I may look at this. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu