Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!ispd-newsserver!ism.isc.com!ico!attc!marbru
From: marbru@attc.UUCP (Martin Brunecky)
Newsgroups: comp.windows.x
Subject: Re: XtAddInput question
Message-ID: <980@attc.UUCP>
Date: 21 Jan 91 15:41:43 GMT
References: <1991Jan18.200129.21797@linus.mitre.org>
Reply-To: marbru@auto-trol.UUCP (Martin Brunecky)
Distribution: na
Organization: Auto-trol Technology, Denver
Lines: 27

In article <1991Jan18.200129.21797@linus.mitre.org> daf@cavern.mitre.org (Dennis A. Franciskovich) writes:
>when the file *can* be read, not just when there is new input to read.

   Can someone explain to me what are the semantics and mechanisms of a file
   (not a pipe or a socket) that *can* be read but there is NO *new input* 
   to read ?????

   In my (aparently silly) imagination a readable file always has data
   available - i.e. there is nothing to wait for (except for disk latency
   which is totally unpredictable).
   The only questions may arise in regards to the EOF handling.

   In my *opinion*, the XtAddInput is intended as an alternate source of
   *input events*, not *application data*. I somehow can not imagine
   a *file* being a source of time-sequenced input events (though I can
   imagine a pipe there). Thus, it seems to me understandable that the
   XtAddInput does NOT automatically deal with EOF on a file, as the
   semantics of the "death of the input event source" is likely to be
   application specific.

   

-- 
=*= Opinions presented here are solely of my own and not those of Auto-trol =*=
Martin Brunecky                           {...}sunpeaks!auto-trol!marbru
(303) 252-2499                        (sometimes also:  marbru@auto-trol.COM )
Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404