Re: Seppuku and x_IO_error_handler()
[This is from the Xt FAQ. I believe as long as XtCloseDisplay() is
called and you don't return from the error handler, Xlib and Xt will
handle the problem]
The difficulty arises because the Xlib design presumed that an I/O
error is always unrecoverable and so fatal. This is essentially true
for a single display X based application, but not true for a
multiple display program or an application that does things other than
display information on an X server. When an X I/O error occurs the
I/O error handler is called and _if_ it returns then an exit()
happens. The only way around this is to use setjmp/longjmp to avoid
returning to the I/O error handler. The following code fragment
demonstrates this:
#include <setjmp.h>
jmp_buf XIOrecover;
void
XIOHandler (dpy)
Display *dpy;
{
destroyDisplay (dpy);
longjmp (XIOrecover, 1);
}
main ()
{
...
if (setjmp (XIOrecover) == 0)
XSetIOErrorHandler (XIOHandler);
XtAppMainLoop (app_context);
}
The destroyDisplay() is something that given a Display pointer can go
back to the application specific data and perform any necessary
cleanup. It should also call XtCloseDisplay().
For those of you unfamiliar with setjmp/longjmp, when setjmp() is
first called it returns a 0 and save's enough information in the
jmp_buf that a latter execution of longjmp() can return the program to
the same state as if the setjmp() was just executed. The return value
of this second setjmp() is the value of the second argument to
longjmp(). There are several caveats about using these but for this
purpose it is adequate.
Some other problems you might run into are resource converters that
improperly cache resources. The most likely symptoms are Xlib errors
such as BadColor, BadAtom, or BadFont. There may be problems with the
total number of displays you can open since typically only a limited
number of file descriptors are available with 32 being a typical
value. You may also run into authorization problems when trying to
connect to a display.
There was much discussion in comp.windows.x about this topic in
November of 91. Robert Scheifler posted an article which basically
said this is the way it will be and Xlib will not change.