Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcdc!rml
From: rml@hpfcdc.HP.COM (Bob Lenk)
Newsgroups: comp.sys.hp
Subject: Re: terminal i/o
Message-ID: <5570215@hpfcdc.HP.COM>
Date: 14 Jun 89 02:19:45 GMT
References: <3836@sdsu.UUCP>
Organization: HP Ft. Collins, Co.
Lines: 35

>			fd = open( "/dev/tty", O_RDONLY );
>
>			ioctl( fd, TCFLSH, 0 );		/* flush input buffer */
>
>			c = getc( stdin );		/* stdin and fd both
>						  	   control terminal */

The most likely cause of your problem is that the buffered input that
sometimes causes problems is being buffered by the standard I/O library,
not the terminal driver.  TCFLSH bypasses the standard I/O library.  You
can turn off standard I/O buffering with setbuf(3S) or setvbuf(3S), or
use read(2) directly instead of the standard I/O library.  If you do use
the standard I/O library, it would be cleaner to use a file descriptor
and FILE pointer that are clearly related (one derived from the other
with fdopen(3S) or fileno(3S)).  This code could behave strangely if
standard input is redirected away from the controlling terminal.

>                                                                Part of the
> "stuff" code is a signal handler which is waking up every 500000 milliseconds

A second possibility is that this signal is interrupting some call and
causing it to fail.  Some ways to deal with this:

	- Check the returns from all system calls and library calls.
	  EINTR errors indicate this problem.

	- Block the signal (presumably SIGALRM) around calls that
	  could be affected in this way (see sigblock(2)).

	- Have your signal handler specify that interrupted system calls
	  be restarted instead of interrupted (see sigvector(2)).

		Bob Lenk
		rml@hpfcla.hp.com
		hplabs!hpfcla!rml