Re: [gtk-list] Re: Window close signal

[Owen Taylor <owt1 cornell edu>]

"Francois JEANMOUGIN" <pingouin@crystal.u-strasbg.fr> writes:

> On Jan 16,  3:47pm, Owen Taylor wrote:
> > Subject: [gtk-list] Re: Window close signal
> >
> > Rob McElrath <mcelrath@isp.nwu.edu> writes:
> >
> > > On a related note, the window manager destroy reports an X I/O error when
> > > used...
> >
> > Not much that can be done about that. There is AFAIK no way of
> > distinguishing the "destroy" function from the server crashing.
> > In fact, Xlib doesn't provide any way of handling such events
> > other than terminating the program.
> >
> > Try it with some other X programs.
> 
> 	As I said before, xterm just complains about "broken pipe". would it be
> possible, for example, if the Gtk app is not build using DEBUG options, that it
> does NOT dump a core when such "crash" happen?
> 
> 	Is there any X guru that knows how xterm handle such signal? Probably
> it tests if the connection to the server is still present when trying to update
> the window, no?

I don't think so.

Compare:

xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server ":0.0"

With (from killing a GTK application)

** ERROR **: sigpipe caught

The same thing is happening. And it is being caught the same way.
The error message is just a bit different.

And GTK tries to do cleanup after the error and hangs...


> P.S.: At least, for the 1.0, you should not dump a core for an event
> that "could" be "normal" for an end-user (my biologists or my
> children, but perhaps yours also ;-), even if you know that this is
> not the way you should close a window.

Any end-user probably should have ulimit -c 0
We can probably make the exit a bit smoother though. We can
set a "connection_exists" variable and not do X cleanup if
it the connection has been lost.

(Another problem occurs if we exit on a signal - we might
be inside X and unable to do X cleanup - some stuff for
the TODO list)

Regards,
                                        Owen