ecf_hap@jhunix.HCF.JHU.EDU (Andrew Poling) (03/02/89)
In article <1182@naucse.UUCP> jdc@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? I've used a MIN value of 0 to effect painless polling. You can also put the timing wait for a loop here instead - that way you spend what would be "wasted" time watching the input. >Thanks to all, patience requested of some, for who knows who else might be >as confused as I appear to be? Confused?...by System V?...Nah! :-) Andy . * . * . * . * . * * . * . * _ . * * . . * andy@gollum.hcf.jhu.edu . * . _/ \ * _ . . * * * . * . \ / \_ _/ \ * _/\ * ap@ipgate.hcf.jhu.edu * \ . * _/ /\ \ / () \_ /\_ / \_* . * . * . . ^ \_ / _/ \ _/ \_/ <> \_ ecf_hap@jhunix.hcf.jhu.edu \ /` <> / <> \_ / <> _ \ * . * . \ \_ () __/ _ \ /\ / \_ ^ \ L64A0429@jhuvm.BITNET . /\ \_ _/ () _/ \_ \_ _/ \_ \___________________________
ka@june.cs.washington.edu (Kenneth Almquist) (03/17/89)
In article <1182@naucse.UUCP> jdc@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