Thanks for all your help, folks.
A brief description of the original problem and the solution I adopted
follows.
The Problem:
============
We have an interaction problem when running Gnu Emacs <VERSION 18.52>
on Sun 4/330s <SunOS4.0.3> and a broadcast message is issued using the "wall"
command.
Normal usage of Gnu Emacs is fine, but the following problem occurs on
a reasonably consistent basis: each time a broadcast message from "shutdown"
(or directly from "wall") hits the screen, users who are inside Gnu see the
message appear - but then find that their terminals hang. This happens on
terminals connected via SpiderPorts (and thus via Telnet) and on Macintoshes
connected via NCSA Telnet across a Kinetics FastPath. It also happens if a
user is logged in from another UNIX host over the ethernet.
No further action is possible for that user, although control returns
to the terminal if the Gnu Emacs process is killed. We also have several SUN3s
running OS4.0.3 (and one still running OS3.4!), but they do not suffer from
this problem.
The Response:
=============
Thanks to everyone who took the time and trouble to reply.
It seems that this problem has been noticed by several people. One
suggestion - which seemed the most straightforward - was to get in touch with
the people who maintain GNU. It appears that there is an official patch for
this problem, but I've had no response when I mailed the the suggested address
at MIT (bug-gnu-emacs@prep.ai.mit.edu).
It was also suggested that I upgrade to 18.55 - which I'll try to
do in the future. However, I needed a quick solution:
The Solution:
=============
It appears that emacs tries to handle flow control itself - which it
manages to do quite successfully most of the time - however, the "wall"
program tends to confuse it by sheer speed. Emacs can't cope - hence the
freeze problem.
I've managed to fix the problem with a patch that was sent to me
by <melissa@edu.columbia.cc.cunixe> (although I believe it originated
elsewhere). This was a simple patch to the emacs source file "process.c",
which seems to have cured the problem - no more frozen emacs processes so far.
Since it's only a few lines, it seemed sensible to include it (for the
benefit of those who expressed interest):
*** /tmp/,RCSt1011148 Wed Feb 28 14:16:27 1990
--- process.c Thu Dec 7 12:54:57 1989
***************
*** 1460,1465 ****
--- 1460,1474 ----
if (read_kbd && detect_input_pending ())
break;
+ /*
+ * patch to prevent Emacs from hanging after a
+ * "wall" is done on SunOS 4.0 systems.
+ */
+ if ((Available | Exception) & input_wait_mask)
+ gobble_input ();
+
+
+
#ifdef vipc
/* Check for connection from other process */
Thanks again to those who mailed suggestions, explanations, and
patches.
------------------------------------------------------------------------------
Roger Burroughes Phone: +44 31 667 1011 x6651 | University of Edinburgh
UUCP: ...!uunet!mcvax!ukc!its63b!cogsci!roger | Centre for Cognitive Science
ARPA: roger%cogsci.ed.ac.uk@nsfnet-relay.ac.uk| 2 Buccleuch Place
JANET: roger@uk.ac.ed.epistemi | Edinburgh EH8 9LW Scotland
------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:56 CDT