Re: Seppuku and x_IO_error_handler()
- First Post
- Replies
- Stats
-
Go to
- ----- 2024 -----
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1998 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
Hrvoje Niksic <hniksic(a)srce.hr> writes:
I'm afraid you are right. The "correct" behaviour is
that killing an
existing X frame deletes all the X frames *on that display*, not on
all displays. If you have only X frames running, it is normal that
XEmacs will exit -- as you say it yourself, that's how X handles
killing.
Yes, and this should not be considered bogus anyway. The semantics of
*killing* a window is really a loss of connection with this particular
display, and it's normal that it affects the whole application. If you want to
delete a single (X) window (XEmacs frame), you have the *delete* window
manager protocol for that. It often appears just before `kill' in the WM
menus.
I have now tried my patch with multiple X connections and the result
is, well, bogus.
Still, I believe my patch should be applied because it at least
attempts to bring some order to the situation, and makes things work
with the TTY consoles.
No problem with me.
> The real pain is that X considers it fatal to loose a
connection,
> even in the case you have several ones.
Yuck! Is there a way around that?
Dunno. One day I'll try to return from a fatal io error handler and
continue calling Xlib on the other displays if I have some. I'd be curious to
see if still works but I doubt it seriously. The other solution I was thinking
of was using a set of set/long jmp stuff to go back some place once we know
that a connection is broken (the io error handler was called), and try to
get rid of the connection ourself. I haven't investigated much yet.
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / E.N.S.T. INF C201.1 mailto:vernaļ¼ inf.enst.fr
/_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 80 72
75634 Paris cedex 13 Fax. (33) 01 45 81 31 19
Glynn Clements
Friday, 28 August
Fri, 28 Aug
12:49 p.m.
New subject: Seppuku and x_IO_error_handler()
Didier Verna wrote:
> > The real pain is that X considers it fatal to loose a
connection,
> > even in the case you have several ones.
>
> Yuck! Is there a way around that?
Dunno. One day I'll try to return from a fatal io error handler and
continue calling Xlib on the other displays if I have some. I'd be curious to
see if still works but I doubt it seriously. The other solution I was thinking
of was using a set of set/long jmp stuff to go back some place once we know
that a connection is broken (the io error handler was called), and try to
get rid of the connection ourself. I haven't investigated much yet.
I don't think that the problem is likely to be in Xlib, as that is
fairly stateless. _XIOError calls exit() in the event that the error
handler returns, but there shouldn't be a problem with longjmp()ing
back to the main loop. I wrote a simple test program which does this
and it appears to work without any ill effects.
Xt may be a different matter, although it could be as simple as
removing the appropriate `Display *' from the XtAppContext structure,
so that XtAppNextEvent doesn't try select()ing on the corresponding
descriptor, and ensuring that you never pass the `Display *' (or a
Widget etc which refers to it) to Xt after that.
I guess that someone will have to try it and see.
--
Glynn Clements <glynn(a)sensei.co.uk>
Glynn Clements
Friday, 28 August
Fri, 28 Aug
2:59 p.m.
New subject: Seppuku and x_IO_error_handler()
I wrote:
Xt may be a different matter, although it could be as simple as
removing the appropriate `Display *' from the XtAppContext structure,
so that XtAppNextEvent doesn't try select()ing on the corresponding
descriptor, and ensuring that you never pass the `Display *' (or a
Widget etc which refers to it) to Xt after that.
I guess that someone will have to try it and see.
Some good news and some bad news.
A simple test case seems to indicate that you can longjmp() out of the
IOErrorHandler as long as you delete the `Display *' from the
XtAppContext (if you don't, select() continuously fails).
The bad news is that:
a) The XtDeleteFromAppContext function is internal to libXt, and
(worse still):
b) XtAppContext is an opaque type. It's actually an `_XtAppStruct *',
and _XtAppStruct is defined in InitialI.h, which is an internal Xt
header. We could just copy the definition, but there's no guarantee
that individual vendors haven't made changes to it.
IOW: there seems to be a solution, but I don't know whether it can be
implemented in a way that doesn't mean that you need the X11 source
code to build XEmacs.
--
Glynn Clements <glynn(a)sensei.co.uk>
9395
days inactive
9395
days old
2 comments
2 participants
tags (0)
participants (2)
-
Didier Verna -
Glynn Clements