[Gllug] "X connection to :0.0 broken"

Qingning Huo qingninghuo at gmail.com
Wed Sep 28 10:19:37 UTC 2005


On 9/27/05, Nix <nix at esperi.org.uk> wrote:
> Yes. A close button should cause the wm to send a signal, but if that
> doesn't work, X will be asked to tear down the connection between X
> and the client, via XKillClient(). (This is exactly what the xkill
> utility does.)

Does that mean somehow xclock failed to respond to the WM_DELETE_WINDOW
event, and therefore the window manager has to do a XKillClient()?

> >> I don't think it's random, I think it's when you use the WM's close
> >> button rather than the one inside the application.
> >
> > The X client here is xclock.  There is no button inside the application,
> > nor any menus.  Try this:
> >
> > xclock && echo ok
> >
> > I get different results randomly.
>
> That's a matter of the return code of xclock. Looking at the source, xclock
> should always exit with success if the WM has killed it by hitting it with
> a WM_DELETE_WINDOW request --- in fact, every exit path from xclock itself
> exits with success. Only the inside of Xlib can exit in any other way.
>

I understand that xlib exit(1) when X connection is down (killed by
XKillClient).
The question is why XKillClient is even used to terminate xclock.  There is no
reason for xclock not to respond to WM_DELETE_WINDOW event.  And why
the result is undeterminate?

By the way, what do you get when running "xclock && echo ok" for a couple of
times?  And what is your window manager?  I am thinkg this maybe a problem
of my window manager (fluxbox).

This is not a problem for xclock, but for any serious application, abnormal exit
from inside xlib denies the program any change to do the cleanup job. 
This could
be a big problem for some programs.

Qingning
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list