home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / misc / volume1 / 8711 / microemacs-3.9 / ue3.9.bugs / comp.sources.bugs_252_000003.msg < prev    next >
Internet Message Format  |  1987-12-03  |  1KB
  1. Path: tut!osu-cis!cbosgd!ihnp4!ptsfa!ames!amdcad!sun!pitstop!sundc!seismo!uunet!nuchat!sugar!karl
  2. From: karl@sugar.UUCP (Karl Lehenbauer)
  3. Newsgroups: comp.sources.bugs
  4. Subject: Re: MicroEMACS works but eats CPU on SysV
  5. Summary: System V uEMACS CPU hogging bug squished
  6. Keywords: MicroEMACS, Microport, USG
  7. Message-ID: <1118@sugar.UUCP>
  8. Date: 26 Nov 87 05:04:18 GMT
  9. References: <1107@sugar.UUCP>
  10. Organization: Sugar Land UNIX - Houston, TX
  11. Lines: 21
  12.  
  13. In article <1107@sugar.UUCP>, I wrote about an apparent problem with
  14. uEMACS under Unix System V.  I dug around and found that they do an 
  15. fcntl to set read with no delay as a means of getting typeahead in
  16. order to figure out to cancel output in progress.  I'm not 100% 
  17. sure that's their object, but that's what it looks like.
  18.  
  19. Anyway, there's a variable, kbdpoll, which is set to TRUE to indicate
  20. that the input has been set to no delay, O_NDELAY, via fcntl.
  21. When 'typahead' is called, if kbdpoll isn't set, typahead sets it and
  22. calls fcntl with O_NDELAY so it can do the read without wait.  When 
  23. 'ttgetc' is called to get a character in the regular manner, if kbdpoll 
  24. is set, ttgetc does an fcntl to turn off O_NDELAY and clears kbdpoll.
  25. The problem is that typahead doesn't set kbdpoll after setting O_NDELAY,
  26. so ttgetc never knows to clear it, resulting in a no-delay loop doing
  27. "while (read(0, &kbdq, 1) != 1);"  
  28.  
  29. Here's the diff:
  30.  
  31. 490a491
  32. >         kbdpoll = TRUE;
  33. -- 
  34.