portable way to do nap()
Brandon S. Allbery
allbery at ncoast.UUCP
Mon Oct 10 01:25:09 AEST 1988
As quoted from <543 at mpx1.UUCP> by erik at mpx1.UUCP (Erik Murrey):
+---------------
| In any case, SysVr2 doesn't support a nap()-like call which is
| very useful for two reasons (that I can think of):
|
| 1. Communications protocols implemented at the user process
| level (e.g. uucico, etc.)
| 2. Character input routines that must distinguish between
| ESC and a function key.
+---------------
May I suggest that for both of these, VMIN and VTIME in the tty driver are
what you should look for?
Input routines:
int baudrate[] = {
50,
75,
110,
134,
150,
200,
300,
600,
1200,
1800,
2400,
4800,
9600,
19200, /* EXTA: change as appropriate */
38400, /* EXTB: change as appropriate */
};
baud_based_timeout(speed, maxlen) {
int timeout;
/*
* 100 below is actually bits_per_char * 10 (for tenths
* of a second). bits_per_char is calculated as the
* data bits + parity bit + stop bits + start bit, and is
* typically 10 (7 + 1 + 1 + 1 or 8 + 0 + 1 + 1).
*/
timeout = maxlen * 100 / baudrate[speed];
}
tty.c_lflags &= ~ICANON;
tty.c_cc[VMIN] = strlen(longest_fkey);
tty.c_cc[VTIME] = baud_based_timeout(tty.c_cflags & CBAUD,
tty.c_cc[VMIN]);
ioctl(0, TCSETAW, &tty);
...
keylen = read(0, &keybuf, tty.c_cc[VMIN]);
if (keylen > 1) { /* function key */
...
}
else { /* regular key, including ESC */
...
}
For communications protocols, set VMIN to the size of the longest packet (in
case it's not obvious: "VMIN" should probably have been called VMAX as far
as its actual usefulness, although there is a rationale for its name) and
VTIME to baud_based_timeout(speed, max_packet_len) [baud_based_timeout() as
above]). Use as above; the timeout catches short packets, the VMIN prevents
the start of the next packet from being read as part of the current packet.
Then check the packet header to see what you got, in conjunction with the
returned length.
Some people will have noticed that I refer to -icanon mode as "packet mode"
-- this is why.
[This has not been discussed before, as far as I know, and it *is* a useful
feature of System V.]
++Brandon
--
Brandon S Allbery uunet!hal.cwru.edu!ncoast!allbery allbery%ncoast at hal.cwru.edu
(LAST RESORT ONLY: allbery at uunet.uu.net) DELPHI: ALLBERY
comp.sources.misc is moving off ncoast -- please do NOT send submissions direct
"So many articles, so little time...." -- The Line-Eater
More information about the Comp.unix.wizards
mailing list