Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-picayune.mit.edu!athena.mit.edu!bjaspan
From: bjaspan@athena.mit.edu (Barr3y Jaspan)
Newsgroups: comp.windows.x
Subject: Re: How do I get XtAppAddInput to work correctly
Message-ID: <1991Jan4.221250.5174@athena.mit.edu>
Date: 4 Jan 91 22:12:50 GMT
References: <1990Dec31.170612.7040@lta.com> <5184@trantor.harris-atd.com>
Sender: news@athena.mit.edu (News system)
Reply-To: bjaspan@athena.mit.edu (Barr3y Jaspan)
Organization: Massachusetts Institute of Technology
Lines: 73

In article <5184@trantor.harris-atd.com>, wdavis@x102c.harris-atd.com (davis william 26373) writes:
|> >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.  Perhaps he was thinking of the case of
XtInputWriteMask, for which the associated procedure *IS* called constantly
(since files/pipes/etc are almost always ready to be written to).  (well, of
course, XtAddInput doesn't so that, it causes XtMainLoop to.)

I have only used XtAddInput for filedescriptors connected to
pipes/sockets/etc, never for a file.  I assure you that it does, in fact,
work.  At the end of the posting there is a sample program demonstrating its
use.

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 (and the program should deal accordingly; in this case, remove the
input procedure).  Howver, future calls to select() on the descriptor will
CONTINUE to indicate that there is data waiting to be read.

So, if your program is not checking that EOF has been reached, the input
procedure will get called constantly once it has been.

Sorry if this is poorly worded, I'm on a slow net connection and can't fix it.

Barr3y Jaspan, bjaspan@mit.edu
Watchmaker Computing

--- snip snip ---

#include <stdio.h>

#include <X11/Intrinsic.h>
#include <X11/StringDefs.h>
#include <X11/Label.h>

void input();

main(argc, argv)
   int argc;
   char **argv;
{
     Widget	top;

     top = XtInitialize("Hello", "World", NULL, 0, &argc, argv);
     (void) XtCreateManagedWidget("label", labelWidgetClass, top,
				  NULL, 0);
     
     XtAddInput(0, XtInputReadMask, input, NULL);
     XtRealizeWidget(top);
     XtMainLoop();
}

void input(client_data, source, input_id)
   caddr_t	client_data;
   int		*source;
   XtInputId	*input_id;
{
     char	buf[BUFSIZ];
     
     printf("Input received on fd %d.\n", *source);
     scanf("%s", buf);
     printf("\"%s\"\n", buf);
}