hedrick@athos.rutgers.edu (Charles Hedrick) (02/29/88)
I was beginning to wonder whether Microport was kidding us all about
the system being multiuser. It seems like I could never do more than
one thing at a time. Well, I found the problem. My major application
is MicroEmacs. It turns out that it has a bug that causes it to loop
when it's looking for input from the terminal, rather than simply
waiting the next character. On my machine, it would do about 1000
system calls per second. As you might imagine, this causes a fair
amount of impact on the system. I'm fairly sure that this problem is
known and has been discussed before, but I couldn't find any record of
the solution. Since I just posted information on porting UEmacs about
a week ago, I thought it would be worth noting the fix. Note that the
bug is that when putting the terminal into non-blocking mode, emacs
failed to set the state variable saying that it had done so. Thus
when normal read is done, the code didn't know to turn non-blocking
mode off. The net effect is that non-blocking mode is done all the
time, and the program goes into a loop rather than waiting for a
character to be typed. (Now if we can just get Uport to fix cc and ld
so they use my version of malloc or something similar, system
performance will be reasonable.)
*** termio.c.BAK Mon Feb 29 02:55:48 1988
--- termio.c Mon Feb 29 03:35:40 1988
***************
*** 488,493
{
if( !kbdpoll && fcntl( 0, F_SETFL, kbdflgs | O_NDELAY ) < 0 )
return(FALSE);
kbdqp = (1 == read( 0, &kbdq, 1 ));
}
return ( kbdqp );
--- 488,494 -----
{
if( !kbdpoll && fcntl( 0, F_SETFL, kbdflgs | O_NDELAY ) < 0 )
return(FALSE);
+ kbdpoll = TRUE;
kbdqp = (1 == read( 0, &kbdq, 1 ));
}
return ( kbdqp );