On Sun, 18 Jul 2004, Thomas Dickey wrote:
When using kinput2 with xterm, if kinput2 is killed, xterm dies, too.
Very undesirable, as kinput2 needs to be restarted when its
configuration options are changed. GTK2 programs work fine with kinput2
restarts, so xterm should, too.
The current version of XTerm in Debian testing ("sarge") is XTerm #187
(2004-04-27).
Can you still reproduce this problem?
I tried to reproduce the problem today but could not. (If it's still a bug,
I'll need more information about the environment, procedure, etc).
This was harder to reproduce than I expected. I thought it'd always
happen, but that's not true (I just tried xterm briefly, noticed a
problem, and went back to using gnome-terminal). I haven't checked how XIM
works, but apparently you need to have sent some request to kinput2,
after which kinput2 has to die before responding, and *then* the client
application freezes. When I said xterm "dies", I was being unclear.. It
doesn't exit.
A way to reproduce this for all X apps I tested:
1. kill -STOP <kinput2pid>
2. freeze application xyzzy by causing it to use XIM
3a. if you still wish to use the app, kill -CONT <kinput2pid>
3b. otherwise, kill -9 <kinput2pid>. Prepare to kill -9 the app, too.
Nothing seems to help at this point. If you strace the app, you'll
see that it does selects, reads, etc. to get X events, but some of
those reads just return EAGAIN, even if that doesn't normally happen.
EAGAIN isn't supposed to be a fatal error, but a kill -9:ed process
won't ever be responding again, now will it? :-)
The difference between gnome-terminal and xterm is that it only takes one
keystroke in step 2 to temporarily freeze xterm, while gnome-terminal
requires pressing shift-space (the conversion mode switch key).
The way to freeze xterm without kill -STOPping kinput2:
1. Start kinput2.
2. Start a new xterm.
3. Type "kill <kinput2pid>" in the xterm and press enter.
4. If you're lucky (and I seem to always be), xterm is now permanently frozen.
Probably because of the final enter key press..
The right thing to do would IMHO be to fix XIM usage, or XIM itself if
this is an inherent problem, but I've no idea if this is feasible. At
least xterm is not alone in this. Not routing everything through XIM would
be one "solution", but is it really better than just saying "Don't Do
That, Then"? Dunno, really.. Would seem like an ugly workaround to me.
Programs just shouldn't freeze (semi)permanently if a XIM server dies or
is kill -STOPped. OTOH, XIM has its flaws, and some people are working on
a replacement.. (see iimf)
As you can avoid problems just by being careful to restart kinput2 from a
non-XIM-using terminal, this is just a mild annoyance. In any case, if it
isn't fixed in some fashion, it should probably be documented in the BUGS
section on the man page.
