Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU
Newsgroups: comp.windows.x
Subject: Re: How do I get XtAppAddInput to work correctly
Message-ID: <9101051037.AA02347@lightning.McRCIM.McGill.EDU>
Date: 5 Jan 91 10:37:47 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 46

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

> wdavis is incorrect; XtAddInput calls the procedure when there is
> DATA TO READ.  All XtAddInput does, for functions registered with
> XtInputReadMask, is call select and then calls those procedures whose
> filedescriptor is set in the fdset returned from select.

This is not "when there is DATA TO READ".  Even ignoring the question
of select()'s semantics when applied to files, it sometimes returns
when no data are available, such as a socket connection which has
reached EOF (ie, all write ends shut down).

> I have only used XtAddInput for filedescriptors connected to
> pipes/sockets/etc, never for a file.

Then why are you making pronouncements about what it - or rather, the
presumably related XtAppAddInput - does when applied to files?

> Perhaps your problem is the result of peculiar select() semantics.
> When EOF is reached on a filedescriptor, select() will return that
> *there is data waiting to be read on it* even though there isn't.
> Any subsequent read() from that descriptor will return 0 bytes, which
> indicates that it has been closed

If it had been closed, the read would return -1 with errno set to EBADF
(unless of course something else had been opened up since, and gotten
the same descriptor).  0 means the descriptor is still open, but at
EOF.

The semantics select() is supposed to provide are not entirely clear.
All the descriptions available to me simply say "ready for reading".  I
have seen this stated as "a read() will not block", which is what I
observe from sockets.  I, too, have not tried using select() on files,
but if it truly does provide "read() will not block" indications, then
select()ing a file for reading will always indicate readability.
(Unless, presumably, the file is on a dead NFS server :-)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu