Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!rex!uflorida!mlb.semi.harris.com!trantor.harris-atd.com!x102c!wdavis
From: wdavis@x102c.harris-atd.com (davis william 26373)
Newsgroups: comp.windows.x
Subject: How do I get XtAppAddInput to work correctly
Message-ID: <5184@trantor.harris-atd.com>
Date: 4 Jan 91 21:28:24 GMT
References: <1990Dec31.170612.7040@lta.com>
Sender: news@trantor.harris-atd.com
Reply-To: wdavis@x102c.ess.harris.com (davis william 26373)
Organization: Harris Corporation GSS, Melbourne, Florida
Lines: 54

In article <1990Dec31.170612.7040@lta.com> 
with Subject: Frequently Asked Questions about X with Answers 3/3
   [long monthly posting]
xug@lta.com (X User's Group) writes:
>Subject: 72)  Why does XtAppAddInput not work as described?
>I am using XtAppAddInput to read from a file, but the function is called even
>when there isn't input pending.
>
>	XtAppAddInput is actually working as it is supposed to. When used on
>files, it is called whenever the file is READY to be read, not when there is
>new data to be read. The file is almost always ready to be read, however, if 
>only because you can spin back to the beginning and read data you've read 
>before.

This sounds like a rationalization of why the bug is now to be
called a feature.  Given this explanation, any open file descriptor
can be considered "ready to be read".

> The result is that your function will almost always be called every
>time around XtMainLoop().

Right - and that is a bug - not a feature!

>	To get the type of interaction you are expecting, add this line to
>the beginning of your function to test whether there is new data:
>	     if (ioctl(fd, FIONREAD, &n) == -1 || n == 0) return;
>
>[courtesy Dan Heller (argv@ora.com); 8/90]

But this does not address the original problem because it is still
calls the procedure even when there is nothing really ready to be
read.  I already have a check for when the read of the file descriptor
returns a zero to ignore the call.  Lots of overhead.  But the bigger
problem is that when there is a file descriptor that is always ready to
read (because it is always open) then the Work Process never gets
called.  So, how do I get the brain damaged Xt logic to stop calling
my input function long enough to execute a background work process?
I do not want to close the file descriptor because I will not know
what I have already read when I open it again.  I do not want to
remove the input because then I will have no way to know that the
file has been appended to (or is there a way to know that?).
And I cannot avoid using a background work process because that
code is part of a purchased package.

I will remove the input for X if there is a way to know when the
file has something more added to the end of what has already been
read.  Any ideas on this?  Lacking that is there any chance that
the Xt logic will get fixed?  How about an option (we could call it
XT_GLITCH_INHIBIT) that will make the input stuff work rationally?
Or is this really an underlying problem with the select call?

My preference is for a work around that will get me past my short
term problem without an Xt rewrite.  I can tolerate the extra overhead
if the Work Process will just get executed.