Path: utzoo!mnetor!uunet!nuchat!sugar!karl
From: karl@sugar.UUCP (Karl Lehenbauer)
Newsgroups: comp.sources.d
Subject: Re: uEmacs 3.9 on SCO Xenix
Message-ID: <1497@sugar.UUCP>
Date: 27 Feb 88 19:25:40 GMT
References: <7@libove.UUCP> <929@silver.bacs.indiana.edu> <1107@sugar.UUCP>
Distribution: na
Organization: Sugar Land UNIX - Houston, TX
Lines: 31
Summary: System V uEMACS CPU hogging bug squished

In article <7@libove.UUCP> libove@libove.UUCP (Jay Mathew Libove) writes:
>I recall seeing some stuff go by about a modification to uEmacs 3.9
>that rids it of this CPU hogging behavior. Can someone please send me
>the information?

In article <929@silver.bacs.indiana.edu>, backstro@silver.bacs.indiana.edu (Dave White) writes:
> I would like this as well.  Many thanks in advance.

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.  

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;

-- 
"I just thought of something funny...your mother." - Cheech Marin
..!uunet!nuchat!sugar!karl, Unix BBS (713) 438-5018