[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