Path: utzoo!attcan!uunet!lll-winken!ames!xanth!nic.MR.NET!hal!ncoast!allbery From: allbery@ncoast.UUCP (Brandon S. Allbery) Newsgroups: comp.unix.wizards Subject: Re: printf, data presentation Message-ID: <13327@ncoast.UUCP> Date: 14 Jan 89 00:25:46 GMT References: <19@xenlink.UUCP> <8800006@gistdev> Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery) Followup-To: comp.unix.wizards Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 44 As quoted from <8800006@gistdev> by flint@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@hal.cwru.edu ncoast is registering as "ncoast.org" -- watch for the official announcement! Send comp.sources.misc submissions to comp-sources-misc@.