Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

comp.windows.x Frequently Asked Questions (FAQ) 7/7
Section - 165) How can my Xt program handle socket, pipe, or file input?

( Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 - Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Counties ]


Top Document: comp.windows.x Frequently Asked Questions (FAQ) 7/7
Previous Document: 164) What are these "Xlib sequence lost" errors?
Next Document: 166) Why doesn't my Xt timer go off when it is supposed to (sic) ?
See reader questions & answers on this topic! - Help others by sharing your knowledge

It's very common to need to write an Xt program that can accept input both
from a user via the X connection and from some other file descriptor, but
which operates efficiently and without blocking on either the X connection or
the other file descriptor.

A solution is use XtAppAddInput(). After you open your file descriptor, use
XtAppAddInput() to register an input handler. The input handler will be
called every time there is something on the file descriptor requiring your
program's attention. Write the input handler like you would any other Xt
callback, so it does its work quickly and returns.  It is important to use
only non-blocking I/O system calls in your input handlers.

Most input handlers read the file descriptor, although you can have an input
handler write or handle exception conditions if you wish.

Be careful when you register an input handler to read from a disk file.  You
will find that the function is called even when there isn't input pending.
XtAppAddInput() is actually working as it is supposed to. The input handler
is called whenever the file descriptor is READY to be read, not only when
there is new data to be read. A disk file (unlike a pipe or socket) is almost
always ready to be read, however, if only because you can spin back to the
beginning and read data you've read before.  The result is that your function
will almost always be called every time around XtAppMainLoop(). There is a
way to get the type of interaction you are expecting; add this line to the
beginning of your function to test whether there is new data:

	     if (ioctl(fd, FIONREAD, &n) == -1 || n == 0) return;

But, because this is called frequently, your application is effectively in a
busy-wait; you may be better off not using XtAppAddInput() and instead
setting a timer and in the timer procedure checking the file for input.

[courtesy Dan Heller (argv@ora.com), 8/90; mouse@larry.mcrcim.mcgill.edu 5/91;
Ollie Jones (oj@pictel.com) 6/92]

There are two alternatives: the simple one is to use XtAppAddTimeout instead
of XtAppAddInput and check for input occasionally; the more complex solution,
and perhaps the better one, is to popen or fork&exec a child which does
blocking reads on the file, relaying what it has read to your application via
a pipe or a socket. XtAppAddInput will work as expected on pipes and
sockets.

Thanks to Kaleb Keithley (kaleb@x.org); 12/93]

User Contributions:

Comment about this article, ask questions, or add new information about this topic:




Top Document: comp.windows.x Frequently Asked Questions (FAQ) 7/7
Previous Document: 164) What are these "Xlib sequence lost" errors?
Next Document: 166) Why doesn't my Xt timer go off when it is supposed to (sic) ?

Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 - Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
faq%craft@uunet.uu.net (X FAQ maintenance address)





Last Update March 27 2014 @ 02:12 PM