Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!rutgers!sri-spam!nike!lll-crg!lll-lcc!qantel!intelca!oliveb!glacier!cdp!jeff
From: jeff@cdp.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Keyboard check under UNIX Sys V?
Message-ID: <4300003@cdp>
Date: Tue, 30-Sep-86 15:11:00 EDT
Article-I.D.: cdp.4300003
Posted: Tue Sep 30 15:11:00 1986
Date-Received: Sat, 4-Oct-86 04:56:42 EDT
References: <30896@arizona.UUCP>
Lines: 25
Nf-ID: #R:arizona.UUCP:30896:cdp:4300003:000:1228
Nf-From: cdp.UUCP!jeff    Sep 30 12:11:00 1986


i'm not sure if i agree that using VMIN/VTIME and raw mode is
the "preferred" way of doing unblocked reads, but it is one way.
your preference may depend on your application.  in the applications
i've done, i prefer to use O_NDELAY.  anyway, here are a few
issues you might want to consider:

- if you use "raw" mode, this means that your application must
provide its own erase and kill handling.
- a note on ungetc: you cannot ungetc something before you do a
(buffered) stdio read from the input stream.  this is documented
in the manual page, although in practice, not all systems are
this strict.
- an alternative to ungetc is to maintain a one character lookahead
buffer.  if you have one central input routine, then this change
is easy to pop into place.  if you use many different input routines,
then you have more work on your hands.
- the alternative approach is to open the input stream with
O_NDELAY.  however, since you probably don't want unblocked
reads all the time, a convenient hack is to open up a separate
descriptor for stdin with O_NDELAY, and use that descriptor
only for readahead.

if this sounds unnecessarily complicated, that's because it is.
the berkeley users have FIONREAD, which is much nicer...