Xref: utzoo comp.emacs:4495 gnu.emacs.bug:136 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cs.utexas.edu!milano!titan!janssen@titan.sw.mcc.com From: janssen@titan.sw.mcc.com (Bill Janssen) Newsgroups: comp.emacs,gnu.emacs.bug Subject: Re: 18.52 and X11 Message-ID: <1464@titan.> Date: 28 Oct 88 00:28:53 GMT References: <4933@garfield.MUN.EDU> <358@infovax.lan.informatik.tu-muenchen.dbp.de> <88Oct25.175431edt.40365@dopey.white.toronto.edu> Sender: janssen@titan. Reply-To: janssen@titan.sw.mcc.com (Bill Janssen) Followup-To: comp.emacs Organization: MCC Software Technology Lines: 24 In-reply-to: cks@white.toronto.edu (Chris Siebenmann) I had a problem that may or may not be similar with a branch variant of GNU Emacs we run here, under X. Every so often it would go into a very compute-intensive loop, but not doing anything to the X-window it was running in. We tracked this down to a bug in the "fcntl" code for sockets, in that only the group leader of the process group received SIGIO's, though the code *apparently* sets up the groups so that all members of the group will receive SIGIO. The emacs code under X basically sits in a select statement, waiting for input to be delivered from the X server or from some dependent process. When input comes in from the X server, it expects to see that a SIGIO has happened before the select has returned. When the select returns, Emacs checks a flag to see if a SIGIO has been delivered. If it has, it goes to read the X socket. If not, it goes back into its select. Under some conditions, Emacs is not the group leader of its process group, and never receives SIGIO. If you are running with INTERRUPT_INPUT, it will continue to bounce out of and back into that select statement forever. A quick fix is to slap a "setpgrp" statement in somewhere, so that Emacs is always the process leader of its process group. Another fix, and I thought this was already in the 18.51 code, was to check the input a bit differently when coming out of the select statement. Bill