Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!itk.unit.no!ojr From: ojr@itk.unit.no Newsgroups: gnu.emacs.bug Subject: emacs hangs with 100% CPU after [r]wall Message-ID: <8904131205.AA12055@inge.itk.unit.no> Date: 13 Apr 89 12:05:23 GMT Sender: daemon@tut.cis.ohio-state.edu Distribution: gnu Organization: GNUs Not Usenet Lines: 51 Description: We are running SUN OS4.0.1 and emacs 18.53.3. When a broadcast message arrives at a terminal/window where emacs is running, emacs stops accepting input and hangs with 100% cpu being used. ^G does not work. It is possible to restart emacs with an INT signal to the emacs process from another window. What I found: Something strange happens with the SUN i/o system when a broadcast is delivered. I looks as if no signals are delivered to the emacs process when the signal originates in keyboard events (neither SIGINT or SIGIO). The function 'wait_reading_process' loops forever because select (line 1373) returns with bit 0 in 'Available' set, instead of delivering the SIGIO signal. As this bit is ignored in the function the result is an eternal active wait. Solution (hack?): What I did was checking on bit 0 in 'wait_reading_process' and sending the missing SIGIO to emacs if the bit is set. This looks as if it fixes the problem. The diff is listed below: lisa% diff -c2 process.c~ process.c *** process.c~ Sat Oct 8 17:24:20 1988 --- process.c Thu Apr 13 11:53:26 1989 *************** *** 1399,1402 **** --- 1399,1413 ---- error("select error: %s", sys_errlist[xerrno]); } + #ifdef SUN_REGTEK + else if (nfds > 0 && (Available & 1)) + { + /* + * Input from standard input should go to + * interrupthandler. + */ + + kill(getpid(), SIGIO); + } + #endif /* Check for keyboard input */ You have to have -DSUN_REGTEK in the compiler command when compiling. process.c. Best regards ojr@itk.unit.no Ornulf Jan Rodseth SINTEF Dep. of Automatic Control, N-7034 TRONDHEIM NORWAY