Uses of read MIN time (Was: termio under SysV (kbdhit() and getch()))

Kenneth Almquist ka at june.cs.washington.edu
Fri Mar 17 12:34:25 AEST 1989


In article <1182 at naucse.UUCP> jdc at naucse.UUCP (John Campbell) writes:

>>It turns out I misread the documentation.  Unlike another (to remain
>>unamed) operating system I use, the MIN time is not the timeout value
>>of the read, but rather the required number of 1/10 seconds the read
>>must take!  Anyone want to tell me how useful this is?

You are still confused.  "A read will not be satisfied until at least
MIN characters have been received or the timeout value TIME has expired
between characters."  For example, suppose you are writing an implemen-
tation of the UUCP protocol.  You set VMIN to 72 (I think) and VTIME to
1.  Then you start receiving the file, which is sent in 72 character
packets.  Every time a packet is received, the operating system notices
that it has 72 characters and returns the characters to the user, and
everything works fine until you get to the last packet of the file.
The last packet of the file will be shorter than 72 characters (unless
the size of the file is an exact multiple of the packet size), so the
system will receive the last character of the last packet, notice that
it doesn't have 72 characters yet, and wait for another character.  Now
VTIME comes to the rescue.  A nominal 0.1 seconds (actually more like
0.15 seconds) after receiving the last character the system will notice
that the time between reading successive characters has exceeded VTIME,
and will return the characters that it has received to the user.  This
is how the last packet is read.  A key point is that VTIME takes effect
only after a character has been received, so it should never cause read
to return zero characters.

Why have VMIN at all, rather than using VTIME to detect the end of all
the packets?  The answer is that using VTIME introduces delays in the
protocol while the operating system times out waiting for the next
character, so it is better to use VMIN when possible.  Why bother with
all this stuff anyway, rather than having the operating system simply
return characters to the user program as they are received?  The answer
is that returning a single character at a time works fine--if you don't
care about performance.  Here is a simple test to see if the implemen-
tation of UUCP on your system uses the VMIN/VTIME feature:  Start up a
UUCP transfer on an otherwise idle system.  If the processor idle time
is greater than 90%, your UUCP uses VMIN/VTIME.  If the processor idle
time is zero, you UUCP reads a character at a time.
				Kenneth Almquist



More information about the Comp.sys.att mailing list