home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / os2 / advocacy / 8589 < prev    next >
Encoding:
Text File  |  1992-11-19  |  1.3 KB  |  28 lines
  1. Newsgroups: comp.os.os2.advocacy
  2. Path: sparky!uunet!caen!destroyer!news.iastate.edu!jws
  3. From: jws@iastate.edu (James William Shoemaker)
  4. Subject: Re: PC Week, November 9
  5. Message-ID: <Bxz7B9.B7H@news.iastate.edu>
  6. Sender: news@news.iastate.edu (USENET News System)
  7. Organization: Iowa State University, Ames, IA
  8. References: <1992Nov13.161920.24065@panix.com> <pathak-171192171854@virtual.mitre.org>
  9. Date: Thu, 19 Nov 1992 18:28:19 GMT
  10. Lines: 16
  11.  
  12.  
  13. > In some cases, even this may be true.  If my I/O device buffers input, I
  14. > have the choice of processing data as a single byte (interrupt-driven I/O)
  15. > or in chunks (polled I/O).  In many cases, it is more efficient to process
  16. > data in chunks (in some cases one might be required to process data in
  17. > chucks).  Then the choice is to either let the I/O hardware buffer and to
  18. > process the data in chunks or to grab each byte and buffer the data
  19. > manually until enough data is received so processing can be done.  I don't
  20. > know about you, but I would rather let the hardware do the buffering.
  21.  
  22.     If the device can buffer input, why not tell it to only interrupt you
  23. if the buffer is X% full?  The 16550 works that way.  Just because a device is
  24. interrupt driven doesn't mean it interrupts you every byte, just when it wants
  25. servicing.
  26.  
  27.                 JWS
  28.