----------------------------------------------------------------------

It does, however Unix semantics for when I/O is ready for a file does
not fit most peoples' intuitive model.  In Unix terms a file
descriptor is ready for reading whenever the read() call would not
block, ignoring the setting of optional flags that indicate not to
block.  This works as expected for terminals, sockets and pipes.  For
a file the read() will always return but the return indicates an EOF
-- i.e. no more data.  The result is the code in the Intrinsics always
calls the input handler because it always thinks something is about to
be read.  The culprit is the select() system call or on SYSV based
OS's it is the poll() system call.

How to get around this on a Unix system?  The best approach is to use
another process to check for available input on the file.  Use a pipe
to connect the application with this other process and pass the file
descriptor from the pipe to XtAppAddInput().  A suitable program on
BSD systems is "tail -f filename".

It's rumored that select() on some systems is not _completely_
reliable.  In particular:

	- IBM AIX 3.1: this is one where it would work for a while
	  (several thousand times) and then stop until some other
	  event woke it up. This seemed to be the result of a race
	  condition in the Kernel.  IBM claims to have a fix for this.

	- Pyramid, doesn't work at all.

	- Ultrix (and possibly others where pipes are implemented as
	  sockets), wasn't completely broken, but although the writing
	  side wrote in 512 byte blocks the reading side received it
	  all broken up as if it was being put into the pipe a byte at
	  a time.  You can waste a lot of time by reading small blocks
	  (get raound it by detecting the situation and having
	  select() ignore the pipe for 10 mseconds - by then it had
	  been given the whole block).


Note that all the above descriptions used Unix terminology such as
read(), file descriptor, pipes, etc.  This is an OS dependent area and
may not be identical on all systems.  However the Intrinsic designers
felt it was a common enough operation that it should be included with
part of the toolkit.  Why they didn't also deal with signals at this
point I don't know.