Brian, I can't tell if you have enough of an understanding of X11 to write a proposed solution that actually makes sense. At least, I can't make any sense out of your proposal.
The problem is that we have to wait for events by calling select (). Normally, select () returns when the other end of the connection is closed and it sets a flag to indicate that the other end of the connection has closed. In X11, however, when the server is about to reset or shutdown it loops through the list of all connected clients and, instead of closing their connections, it simply ``kill''s them without warning. Yes, X11 is beautifully engineered. :) Trust me, I have read the source code and searched all over the web for a solution to this. This is a well-recognized short coming of the X11 protocol. However, there has to be some workaround because applications written using Xt do not get explicitly killed when the server shuts down. Thus, there has to be some sort of signal that indicates that the server is about to shutdown and that we should not call select () again. In one of my last few posts I mentioned that there appears to be some convention that the mouse coordinates move to a certain location on the root window just before the server shuts down. This mouse message is sent to all clients and we can use this mouse message as a signal to not call select () again. However, I do not know the details of this mouse message, nor do I even know for sure if it exists. This is merely an impression that I got from looking at the source code to another program that does not get killed when the X server shuts down. It is one thing to chat about this... it is quite another to look at the X Server and Xlib source code and try to come up with a solution that works. Harold Brian Gallew wrote: >Harold L Hunt II said: > > >>I have searched for months and months for a way to receive a >>definite signal that the X server is about to shutdown. There is a >>hook provided by most window managers to indicate that the display >>is closeing, but it has so far given mixed results. The last idea >>I saw was in the x2x (I think) source code, which interfaces with >>the raw Xlib, just like xwinclip. It looked like x2x was watching >>for a move message for the mouse to (0, 0) (or some other special >>point) and it took this as a signal to close the X client >>connection. >> >> > >Please correct me if I'm wrong, but isn't it the case that you merely >need to be able to gracefully handle the "X server is dead" case >rather than knowing the X server is about to exit? > >If so, perhaps this (grotty kludge) is what you want. During >initialization, after the initial connection to the X server is made >(using the appropriate X library funtions), MANUALLY create another >connection to the X server (e.g. open a socket and send some >messages). Then, before any X operations, try accessing the manual >socket to make sure X is still up (e.g. ping the server). If the ping >fails, then you can un-hook your event gracefully. Yes, there's still >a window where you ping, the server goes down, and then you try your >operation, but I doubt you really want to do it all by hand. The ping >will be painful enough. > >This idea has come to me through the python-xlib project, which >basically implements libX11 in pure python code (except for the socket >layer, of course). My understanding is that the fundamental problem >is that the X11 functions generally force an application exit when >they fail to do server absence. > > > >