Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!nuchat!sugar!karl From: karl@sugar.UUCP (Karl Lehenbauer) Newsgroups: comp.sources.bugs Subject: Re: MicroEMACS works but eats CPU on SysV Message-ID: <1118@sugar.UUCP> Date: Thu, 26-Nov-87 00:04:18 EST Article-I.D.: sugar.1118 Posted: Thu Nov 26 00:04:18 1987 Date-Received: Sun, 29-Nov-87 17:46:17 EST References: <1107@sugar.UUCP> Organization: Sugar Land UNIX - Houston, TX Lines: 21 Keywords: MicroEMACS, Microport, USG Summary: System V uEMACS CPU hogging bug squished In article <1107@sugar.UUCP>, I wrote about an apparent problem with uEMACS under Unix System V. I dug around and found that they do an fcntl to set read with no delay as a means of getting typeahead in order to figure out to cancel output in progress. I'm not 100% sure that's their object, but that's what it looks like. Anyway, there's a variable, kbdpoll, which is set to TRUE to indicate that the input has been set to no delay, O_NDELAY, via fcntl. When 'typahead' is called, if kbdpoll isn't set, typahead sets it and calls fcntl with O_NDELAY so it can do the read without wait. When 'ttgetc' is called to get a character in the regular manner, if kbdpoll is set, ttgetc does an fcntl to turn off O_NDELAY and clears kbdpoll. The problem is that typahead doesn't set kbdpoll after setting O_NDELAY, so ttgetc never knows to clear it, resulting in a no-delay loop doing "while (read(0, &kbdq, 1) != 1);" Here's the diff: 490a491 > kbdpoll = TRUE; --