Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site reed.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!reed!alexis
From: alexis@reed.UUCP (Alexis Dimitriadis)
Newsgroups: net.lang.c
Subject: Re: C Input Question? (non-blocking I/O)
Message-ID: <1158@reed.UUCP>
Date: Sat, 23-Mar-85 19:39:41 EST
Article-I.D.: reed.1158
Posted: Sat Mar 23 19:39:41 1985
Date-Received: Wed, 27-Mar-85 02:54:07 EST
References: <522@lsuc.UUCP>
Reply-To: alexis@reed.UUCP (Alexis Dimitriadis)
Distribution: net
Organization: Reed College, Portland, Oregon
Lines: 42

In article <522@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes:

>||>[text cut for brevity. Scott wants non-blocking I/O, that is "read if
>||>data, but don't wait for data.]
>||
>||   ioctl(0,FIONREAD,&charwaiting);
>
>That's fine for BSD (which was the system the questioner wanted it for).
>Anyone have an easy way of doing this for v7? I'm willing to do a
>limited amount of kernel hacking.

  I have gotten the same effect without using non-blocking I/O at all.
I used it to write a real-time "game", so the following is in that context.

If you have the equivalent of setitimer(), which arranges for a signal to
be sent to your process after a specified amount of time, then you can
set the signal handler to be the routine that makes things happen with
time. (e.g., advances the killer ships)  The same routine should also 
reset the timer if it cannot automatically be set to repeat.
(And the handler, if it gets reset!)

  Then the main thread of your program can block waiting for input to
process, and things will happen in `real time' by repeated calls to the
handler.  You have to be careful not to confuse the main thread by altering
things while it is processing input, (e.g. by ignoring the alarm for a
while), and to make sure alarms do not come so 
often that the input never gets read at all, as will be the case if the 
handler takes a while. (You can discard pending alarms or whatever).

  It is fairly straightforward, but may be difficult to debug, since the
control flow is strange.  The safest course is probably to block alarms
while processing input, and unblock them just before a read.  The approach
needs a fairly sophisticated interrupt handler, but can be used where non-
blocking I/O is not implemented. 

	Alexis Dimitriadis 
-- 
_______________________________________________
	  alexis @ reed
	...ihnp4!{harvard|tektronix}!reed
	...decvax!tektronix!reed
	...teneron!reed