mcooper%acamar.usc.edu@OBERON.USC.EDU (Michael A. Cooper) (01/20/89)
Version Info:
Emacs version: 18.51 and 18.52
System: Sun-3 & Sun-4 under SunOS 4.0.1
Problem:
Receiving a wall(1) message while in emacs causes emacs to loop.
Repeat By:
1) Log into a SunOS 4.0 host (via rlogin, telnet, direct
terminals, or start a suntools window).
2) Start emacs.
3) From another login session, run wall and send a message.
Your emacs session is now hung. You should get no response
at all. If you run a "ps aux" and look at the state of that
emacs process you will see it is running straight out. If
you look at the tty modes of that terminal via
stty everything > <TTY>
(where <TTY> is the tty with the emacs running on it) you will
see that most of the "special" tty characters (such as werase,
flush, susp, etc) are not set, but intr is set to ^G. I would
guess that emacs received the ^G from the wall(1) command and
is now looping on interupts.
History:
It looks like the wall(1) command changed the way it wrote
to terminals from SunOS 3.X to 4.0. The old method used
simple fprintf()'s. The new method uses fcntl() to set
FNDELAY and then uses write(). Here's the code fragment from
the 4.0 wall that does the terminal writing:
if ((flags = fcntl(f, F_GETFL, 0)) == -1) {
perror(t);
return;
}
if (fcntl(f, F_SETFL, flags | FNDELAY) != -1) {
i = write(f, mesg, msize);
e = errno;
(void) fcntl(f, F_SETFL, flags);
if (i == msize) {
(void) close(f);
return;
}
if (e != EWOULDBLOCK) {
errno = e;
perror(t);
(void) close(f);
return;
}
}
I've recompiled the old 3.2 wall(1) and used it and it doesn't
produce any problem's with emacs. I suspect that between emacs
and wall fcntl()'ing, the terminal modes get stepped on somewhere.
I don't think there's anything wrong with the above code from
wall(1) so I believe the problem is with emacs.
mike