Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!husc6!frooz!cfa250!mvh
From: mvh@cfa250.harvard.edu (Mike VanHilst)
Newsgroups: comp.windows.x
Subject: Re: XtAddInput problem
Keywords: select
Message-ID: <1771@cfa241.cfa250.harvard.edu>
Date: 12 Nov 89 10:20:14 GMT
Organization: Harvard/Smithsonian Center for Astrophysics
Lines: 61

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.

and procedes to explain how select() works on stdin and stdout.

While in article <294@nap1.cds.wpafb.af.mil>
 staatsvr@asdcds.cds.wpafb.af.mil ( Vern Staats;;) writes:

>  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.

I too, am using name pipes as a convenient mechanism for remote
control of my application while having a functioning user
interface.  My experience has been that problems such as those
discussed above, have much to do with the behavior of the pipe
under different conditions, on different operating systems, and
little to do with how select() is called.  It seems that the
behavior is not precisely defined for BSD4.3 and may differ among
vendors.

To wit: under SunOS 3.5 and 4.0.3, if a pipe is opened to read
and set to block (I open it with O_NDELAY, so as not to block
on the open(), and then use fcntl() without the O_NDELAY, to set
blocking), select() only returns with its flag when something
is in fact available to be read (I never find a read of 0 in
response to being called).  Under Ultrix 3.1, the pipe cannot
block if the pipe is not currently opened for writing by some
process.  It always returns from select(), and fcntl() cannot
change this condition.  (This condition, BTW, is not consistent
as, on occasion, it functions as on the Sun).  Under Ultrix 2.0,
it could be set to block by fcntl(), but reverted to non-blocking
when the writer opened and then closed its end.

The method that seems to work in all cases is to open the pipe
on another descriptor for writing (as a dummy), and not close
that connection until closing the connection for reading.  There
is a catch, in that opening to write may fail if there is no
reader, so the sequence, open to read non-blocking, open the
dummy to write, fcntl() the reader to block, must be followed.
I ifdef this out for the Sun, due to a desire to preserve its
fewer available descriptors, as mentioned in another discussion.
I have not tried opening the pipe read/write as Vern suggests.
My suggestion for any new port, is always to test with tiny
programs just to open for writing and reading with select() to
test that OS's behavior.

Now, if somebody could explain this procedure under SysV (i.e.
Apollo), I would be much obliged.

------
Mike VanHilst 				mvh@cfa.harvard.edu
Smithsonian Astrophysical Observatory	(617)495-7260
60 Garden Street, Cambridge, MA  02138