Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!ark1!nap1!asdcds!staatsvr
From: staatsvr@asdcds.cds.wpafb.af.mil ( Vern Staats;;)
Newsgroups: comp.windows.x
Subject: Re: XtAddInput problem
Keywords: XtAddInput XtAppAddInput select
Message-ID: <294@nap1.cds.wpafb.af.mil>
Date: 9 Nov 89 17:29:19 GMT
References: <8911081827.AA12003@turnpike.sun.com>
Sender: news@nap1.cds.wpafb.af.mil
Reply-To: staatsvr@asdcds.UUCP ( Vern Staats)
Organization: US. Air Force, ASD, Wright-Patterson AFB
Lines: 33

In article <8911081827.AA12003@turnpike.sun.com> argv@SUN.COM (Dan Heller) writes:
>If you've been reading comp.windows.x, you'll see a very short-lived
>discussion about how XtAddInput is broken --I recommend *strongly*
>that you avoid using it till it's fixed.  This includes R4; I checked
>the source.  The problem is that your routine gets called continuously
>rather than, as the spec says, "when there is data to be read."
>

  I have had some success using XtAppAddInput on our Ultrix 3.1 Vaxen.  
In particular, I am sending commands to the X11 application over a 
named pipe (fifo), which is opened with the O_NDELAY flag to return 
errors rather than blocking on reads.  I was able to prevent the input 
callback routine from being triggered continuously by opening the pipe 
for both reading and writing in the X11 program, even though the program 
never writes to the pipe.

  The man page for read(2) says that with O_NDELAY set, read will return
0 to indicate end-of-file rather than the -1 error return if no process 
has the pipe open for writing.  My guess is that the select call in
WaitForSomething() is also affected by whether a process has the pipe 
open for writing or not.
 
  Even after opening a dummy_write file descriptor I was getting two 
calls to the input callback routine for every actual input I sent it.
Putting calls to XtRemoveInput() and XtAddInput() in the input callback
routine (to destroy and then re-install itself) prevents the second call,
although I suspect it may be more efficient just to live with it and do
a quick return in the callback if ioctl says the pipe is empty.

----                                                                       ///
INET:  staatsvr@asd.wpafb.af.mil      Vern Staats  (513) 255-2714      \\\///
UUCP:  -Maybe- nap1!asd!staatsvr       ASD/SCED   WPAFB OH 45433        \XX/
Boolean orthogonal(char *my_opinions, char *employer_opinions)  {return(TRUE);}