Xref: utzoo comp.lang.c:13987 comp.unix.questions:10181
Path: utzoo!attcan!uunet!husc6!bloom-beacon!apple!bionet!agate!helios.ee.lbl.gov!lll-tis!oodis01!uplherc!sp7040!obie!wsccs!terry
From: terry@wsccs.UUCP (Every system needs one)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: input ready under UNIX ??!!??
Keywords: input, unix, help
Message-ID: <763@wsccs.UUCP>
Date: 5 Nov 88 08:14:55 GMT
References: <771@necis.UUCP> <547@poseidon.ATT.COM>
Lines: 57

In article <547@poseidon.ATT.COM>, psrc@poseidon.ATT.COM (Paul S. R. Chisholm) writes:
> <"He seemed like such a nice man . . . and then he turned out to be a writer!">
> 
> In article <771@necis.UUCP>, rbono@necis.UUCP (Rich Bono) writes:
> > HELP!!  how can one (if at all) find out (non-destructivly) if there is
> > any input waiting to be read from stdin???   With the Microsoft-C libraries
> > I can use the kbhit() function which returns TRUE if there are any characters
> > waiting to be input.  Clearing ICANON with a ioctl() for stdin does NOT do
> > what I want.....
> >(follows, an example that uses kbhit() and gets(); odd combination)
> 
> First of all, it sounds like a good idea to package this in a single
> routine with a portable interface.  You may have to entirely rewrite
> the routine to get it to run under the UNIX(R) operating system, but
> it would be called the same as under MS-DOS.

[a lot of non-ideal partial examples deleted]

Or you could call the standard routines for it.  Most Xenix and nearly all
AT-architecture UNIX implementations have rdchk() in either the standard
library or some other on the machine.

The ioctl parameters TIOCQCNT (Terminal Input Output Control Queue CouNT)
or FIONREAD also work nicely everywhere but system V.

The alarm across the signal only gives you blocking to a one second resoloutin,
far too slow to really do anything with.  Besides, when reading from some
devices (say the LAT drivers under ULTRIX) the alarm is just queued rather
than being executed, as the I/O blocks in kernel-mode code.  Bletch.

Using two file descriptors, two pipes and a selectio will work on Berkley; you
for a child process to do your reading and write a single character to the pipe
and read the other end of the pipe and the pipe to the child with a select I/O.
If you get the single character, write it to the pipe again.  This will allow
you to poll the 'keyboard':

                selectio() <------------+----------- keyboard reader (child)
					|
		= character?		|
					|
		yes: character-------->pipe
		no: process character.

The other (much cleaner and nicer and recommended) way would be to use a
semaphore and a child process.

Or you could just drag yourself to use the ioctl commands... but that would mean you have to read SIO(7) in your UNIX manual.  Bummer.


			terry@wsccs

PS: There is an advantage to using a semaphore or signal as the notification
method, rather than polling, as it allows you to go off and do something else
while you're waiting for the I/O to complete and not have to worry about
polling the port with an ioctl() and either replacing the idle process (if only
1 program does this) or dragging the system to it's knees if it's stupid enough
to let you (2 or more processes only).