Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!sun-barr!newstop!sun!turnpike!argv
From: argv%turnpike@Sun.COM (Dan Heller)
Newsgroups: comp.windows.x
Subject: Re: XtAddInput problem
Keywords: XtAddInput XtAppAddInput select
Message-ID: <127714@sun.Eng.Sun.COM>
Date: 10 Nov 89 06:35:01 GMT
References: <8911081827.AA12003@turnpike.sun.com> <294@nap1.cds.wpafb.af.mil> <15783@bloom-beacon.MIT.EDU>
Sender: news@sun.Eng.Sun.COM
Reply-To: argv@sun.UUCP (Dan Heller)
Lines: 28

In article <15783@bloom-beacon.MIT.EDU> bjaspan@athena.mit.edu (Barr3y Jaspan) writes:
> I've seen random discussion about the use of XtAddInput() and about
> how it supposedly does not work.  It *does* work, and I will attempt
> to clear up the confusion.

Ironic -- I was just about to post a followup to my previous message
but you beat me to it.  Well, you said just about what I was going to
say.  I was mistaken about a couple of things which caused the confusion.
Agreed -- this function _does_ work.  However, there is a case where
it's difficult to tell :-)  I think someone pointed out the problem in
another message recently, but didn't emphasize it strongly enough and I
think it should be because it also addresses the confusion I mentioned
above.

I originally said that XtAddInput didn't work because it called your
routine constantly whether there was input there to be read or not.
This isn't true _until it reaches EOF_.  Because the file descriptor
has been modified (FNDELAY I believe), when you're reading on a *file*
and you get to the end of the file, read() no longer returns -1, it
returns 0 and your function is called.  It's hard to tell what the
right thing to do is -- if you want to monitor a file (ala tail -f),
then you're going to have to put up with your function getting called
all the time and your having to do ioctl(fd, FIONREAD, &n) to find
out if there is anything actually there to be read.  The problem here
is that your cpu-usage goes thru the roof.

This is not a problem on pipes and other types of file descriptors.
dan