printf, data presentation

[Brandon S. Allbery]

As quoted from <8800006 at gistdev> by flint at gistdev.UUCP:
+---------------
| way to do a non-blocking read.  I'd like to extend the request one step
| further, to request a _portable_ way to do efficient timed reads.  (I don't
| see any reason why inkey() can't do both: inkey(0) would be non-blocking,
| while inkey(10) would block until either a key arrived or 1 second
| elapsed.)  You can't do this with ioctl() right now, simply because ioctl()
| is too slow to call on every keypress.  (For example, if I want my user
| to type as many keys as they want to within 10 seconds, and then evaluate
| that amount of input, I'm stuck: I have to change the timelimit with each
| successive keypress to be "10 - time_used_so_far", and the only way to do
| so is with an incredibly slow ioctl() call on each keypress.  Some Guru
+---------------

Under System V, as you requested, set VMIN to the maximum number of
characters you want returned (beware, it's a char and some systems use
signed chars; in other words, the maximum portable VMIN is 127) and VTIME to
the timeout in 10'ths of a second.  Be warned that VTIME == 1 is treated the
same as VTIME == 0 and means no timeout (and that the same signed char
argument applies to VTIME).  [VMIN == minimum number of characters to
satisfy request, i.e. return before the timeout if this many characters have
been received.]

At least *some* System V's will treat VMIN == 0, VTIME == 0 as the inkey()
function originally requested.

As mentioned by others, inkey() is a horrible CPU hog.  (It works on
singleuser systems because they can busyloop waiting for a character without
stealing CPU time from other processes.)  Avoid it whenever possible; the
only possible use I can think of for it that won't bring a system to its
knees is to spot-check for characters in order to interrupt something.  For
example, some versions of curses can be configured to abort a refresh() if a
keysoke is detected, e.g. for an editor.  (Jove does this too -- but does
*not* busy loop, it's doing useful work [redrawing the screen] between calls,
and it goes back to a blocking read after the redraw is completed.)

I *hope* that POSIX is dealing with this.

++Brandon
-- 
Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery at hal.cwru.edu
 ncoast is registering as "ncoast.org" -- watch for the official announcement!
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>.