Re: xwinclip re selection polling

[Harold L Hunt II <huntharo at msu dot edu>]

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.
>
>
>
>