home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / linux / 6392 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  3.2 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: <1992Jul21.183946.9138@klaava.Helsinki.FI>
  6. Date: 21 Jul 92 18:39:46 GMT
  7. References: <arumble.711530378@extro.ucc.su.OZ.AU> <1992Jul19.201601.13942@klaava.Helsinki.FI> <arumble.711729320@extro.ucc.su.OZ.AU>
  8. Organization: University of Helsinki
  9. Lines: 60
  10.  
  11. In article <arumble.711729320@extro.ucc.su.OZ.AU> arumble@extro.ucc.su.OZ.AU (Anthony Rumble) writes:
  12. >torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
  13. >
  14. >>The way linux does this is (a) wait for at least one character (VMIN > 0
  15. >>and VTIME > 0), (b) read as many characters as possible, with a timeout
  16. >>of max 0.10 seconds between any of the first 5 characters.  Thus the
  17. >>read can return:
  18. >
  19. >Errm.. Question.. Can you think of a possible USE of this?
  20. >It dosen't seem quite logical to do it this way, it would be
  21. >much more usefull to return on either 5 chars OR timeout regardless
  22. >on the first character.. 
  23.  
  24. Ours is not to wonder why...  Frankly, the above is what the SunOS
  25. man-pages seem to say, and as that's the only info I have on the
  26. subject, that's how linux does things.  SunOS seems to be pretty close
  27. to posix, and following the man-pages has so far worked pretty well.  I
  28. don't know the reasons for the POSIX behaviour, and the man-pages might
  29. be wrong (and I might even have misunderstood), but I'd rather be
  30. conforming to weird standards than have problems porting programs later
  31. on when they expect that behaviour. 
  32.  
  33. As I already mentioned, I'm very open to changing the behaviour: but I
  34. need to have actual "chapter and verse" from the posix standard before I
  35. start changing things.  The current behaviour works with a lot of
  36. programs, and conforms to the only docs I have, so I really need some
  37. strong arguments to change it. 
  38.  
  39. The VMIN/VTIME arguments are currently understood by linux as (note:
  40. this info is only used when not in canonical mode):
  41.  
  42. VTIME = 0 VMIN = 0
  43.     Instant return, reading as many characters as possible from the
  44.     terminal.
  45.  
  46. VTIME = 0 VMIN > 0
  47.     No timeout, and we return once VMIN characters have been read. 
  48.     We still might return before that in case of signals etc, and if
  49.     there are more characters available, they will be read.
  50.  
  51. VTIME > 0 VMIN = 0
  52.     This is a simple timeout-read: we wait VTIME*0.1 seconds or
  53.     until at least one character has arrived.  The read will not
  54.     take more than VTIME*0.1 sec, not counting scheduling etc
  55.     overhead. 
  56.  
  57. VTIME > 0 VMIN > 0
  58.     VTIME*0.1 seconds is an inter-character timer that is started
  59.     after the first character is received, and restarted at each new
  60.     character until VMIN characters have been received.  The read()
  61.     returns at least one character (again not counting signals), as
  62.     the timer comes into play only /between/ characters. 
  63.  
  64. All the above have an upper limit of the given buffer-size: none have a
  65. true lower limit (as they can return less than VMIN characters).  VMIN
  66. isn't meant to be used for packet-sized communication: it's just used to
  67. help decide when/how to accept timeouts.  Can somebody please confirm if
  68. the above is actually the correct behaviour?
  69.  
  70.         Linus
  71.