Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!sun!guy From: guy@sun.UUCP Newsgroups: net.lang.c,net.unix Subject: Re: C I/O Question Message-ID: <5923@sun.uucp> Date: Thu, 7-Aug-86 06:17:24 EDT Article-I.D.: sun.5923 Posted: Thu Aug 7 06:17:24 1986 Date-Received: Sun, 10-Aug-86 05:16:43 EDT References: <1222@inuxc.UUCP> <503@hadron.UUCP> <423@argus.UUCP> Followup-To: net.unix Distribution: net Organization: Sun Microsystems, Inc. Lines: 71 Xref: watmath net.lang.c:10196 net.unix:8854 (Followups redirected to net.unix only, as this no longer has anything to do with C I/O.) > I've had a problem using this on an AT&T 3b5 running Syst 5R2. > It seems that if you set the min character and timeout value, > the timeout does NOT occur until the process receives at least > ONE character. That is exactly what's supposed to happen; there's no problem. The "c_cc[VTIME]" value was NOT originally intended as a read timeout. It was intended to work with the "c_cc[VMIN]" value in a fashion similar to the way that some terminal drivers handle input silos on some terminal multiplexers. The intent is that if data is coming in at a high rate, you don't want to process each character as it comes in; you want to wait until a reasonable number of characters have come in and process them as a group. (In the case of the terminal driver servicing interrupts, this means you get one "input present" interrupt for the entire group, rather than one for each character; in the case of a user program reading from a terminal, this means you do one "read" system call for the entire group, rather than one for each characters.) However, if data is not coming in at a high rate, you don't want to wait for more than some maximum length of time before processing the input; otherwise, the response of the program to the input will be bursty. If the data rate is very variable, you want the system to handle both periods of high and low data rates without having to explicitly switch modes or tweak some parameter. In the terminal driver, this is done by setting the "silo alarm" level to the size of the group, which means that an "input present" interrupt will occur when at least that many characters are available. A timer will also call the "input present interrupt" routine periodically. That routine will drain the silo. This does mean that the "input present interrupt" routine may be called if no input is present, since the timer goes off whether the silo is empty or not. One way of solving this is to adjust the silo alarm level in response to the most recent estimate of the input data rate; in periods of low data rate, the silo alarm level will be set to 1 and the timer can be disabled, since the "input present" interrupt will occur as soon as a character arrives. Another way of solving this is to have the timer be part of the terminal multiplexer, and have it go off only if the silo is not empty. The equivalent of the silo alarm level is the "c_cc[VMIN]" value, and the equivalent of the timer is the "c_cc[VTIME]" value. The S3/S5 terminal driver chooses the equivalent of the second solution to the problem of spurious "input present" indications. In the case of "read"s from the terminal, it is necessary that some way of blocking until at least one character is available be provided. Most programs do not want to repeatedly poll the terminal until input is available; they want to be able to do a "read" and get at least one character from every read. The System III driver did not support the use of the "c_cc[VTIME]" value as a timeout. The System V driver does; my suspicion is that somebody read the documentation, thought it *did* act as a timeout, and filed a bug report when it didn't. Somebody then went off and "fixed" this "bug". If you want a real timeout, so that the read will complete if any data comes in *or* if some amount of time has occurred since the "read" was performed (rather than since a byte of data has come in), you have to set "c_cc[VMIN]" to zero; in that case, the "c_cc[VTIME]" value acts as a read timeout. This is explained in painful detail in the System V Interface Definition and in Appendix C of the IEEE 1003.1 Trial-Use Standard; one hopes the paragraphs devoted to explaining this migrate into the regular manual pages. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)