home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / linux / 6281 < prev    next >
Encoding:
Internet Message Format  |  1992-07-20  |  1.8 KB
  1. Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
  2. From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: Termios question: Semantics of VMIN/VTIME on Linux/SunOS ?
  5. Message-ID: <1992Jul19.201601.13942@klaava.Helsinki.FI>
  6. Date: 19 Jul 92 20:16:01 GMT
  7. References: <9207151400@gandalf.moria> <arumble.711530378@extro.ucc.su.OZ.AU>
  8. Organization: University of Helsinki
  9. Lines: 39
  10.  
  11. In article <arumble.711530378@extro.ucc.su.OZ.AU> arumble@extro.ucc.su.OZ.AU (Anthony Rumble) writes:
  12. >michael@gandalf.moria (Michael Haardt) writes:
  13. >
  14. >>  buff.c_cc[VMIN]=5;
  15. >>  buff.c_cc[VTIME]=1;
  16. >>  tcsetattr(file,TCSANOW,&buff);
  17. >
  18. >>I am no termios expert, but this code is intended to let a
  19. >
  20. >>  read(file,buffer,sizeof(buffer));
  21. >>  
  22. >>read as much characters as available, max sizeof(buffer) and return
  23. >>after a short timeout if there are none.  Ok?
  24.  
  25. The way linux does this is (a) wait for at least one character (VMIN > 0
  26. and VTIME > 0), (b) read as many characters as possible, with a timeout
  27. of max 0.10 seconds between any of the first 5 characters.  Thus the
  28. read can return:
  29.  
  30. -1:
  31.     EINTR - a signal happened (but you usually don't see this: the
  32.             read is mostly re-tried after the signal is handled)
  33.  
  34. 1-5:
  35.     linux got one character, followed by four characters within the
  36.     inter-character timeout given (VTIME = 1 -> 0.1 sec).
  37.  
  38. 6-sizeof(buffer):
  39.     after the fifth character there was actually more data
  40.     available, without any timeout.
  41.  
  42. >I was under the impression that this should actually return on
  43. >either 5 characters recieved, or sizeof(buffer), or timeout..
  44.  
  45. The only thing that I have that explains this all is the SunOS manpage,
  46. so I cannot actually guarantee the above behaviour by linux is correct. 
  47. Could somebody with the POSIX standard available actually check it out?
  48.  
  49.         Linus
  50.