Path: utzoo!telly!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!vax5!sdry
From: sdry@vax5.CIT.CORNELL.EDU
Newsgroups: gnu.emacs.bug
Subject: Re: emacs hangs with 100% CPU after [r]wall
Keywords: emacs.18.52, emacs.18.53
Message-ID: <18404@vax5.CIT.CORNELL.EDU>
Date: 19 Apr 89 23:13:01 GMT
References: <8904131205.AA12055@inge.itk.unit.no>
Sender: news@vax5.CIT.CORNELL.EDU
Reply-To: gelato@astrosun.tn.cornell.edu (Sergio Gelato)
Distribution: gnu
Organization: Cornell Information Technologies, Ithaca NY
Lines: 33

Ornulf Rodseth <ojr@itk.unit.no> recently submitted an analysis of a problem
involving emacs and [r]wall, together with a fix.
We had encountered the same problem here, and I agree with the analysis given.
(Actually, we first detected the problem with 18.52. The same fix applies
to both 18.52 and 18.53.)
I don't see the need for -DSUN_REGTEK, however - my own fix doesn't use it.
So here is an alternate solution (pick your favorite):

*** process.c.old1853	Sat Aug 20 13:27:41 1988
--- process.c	Wed Apr 12 17:00:56 1989
***************
*** 1400,1403 ****
--- 1400,1415 ----
  	}
  
+       /* Bug Fix on 14 March 1989 by S.Gelato, Cornell Astronomy Dept.
+        * --
+        * select(2) keeps returning "stdin ready for read|exception" until
+        * something is done with the descriptor (at the very least, an
+        * ioctl(0, FIONREAD) should be attempted).
+        * get_input_pending() is too lazy, and won't do this unless there
+        * has been an interrupt.
+        * wall(1) apparently causes this condition to be set without any
+        * SIGIO, so we need to do something about it... */
+       
+       if ((Available | Exception) & input_wait_mask) gobble_input();
+       
        /* Check for keyboard input */
        /* If there is any, return immediately

-----------------------------------------------------------------------
Sergio Gelato			gelato@astrosun.tn.cornell.edu
			or	sdry@crnlvax5.bitnet