Re: gdk_input_add() and GdkInputCondition mapping

[Owen Taylor <otaylor redhat com>]

Emil Ong <onge mcs anl gov> writes:

> Hi,
>
> I'm working on an application that creates a display based on input from
> standard in.  I'm using gdk_input_add() to get the input from standard in,
> but I'm having a problem when piping to my application: when the left hand
> side of the pipe closes its standard out (usually on exit), my handler
> continues to be called.
>
> I'll give an example that illustrates this:
>
> #include <stdio.h>
> #include <unistd.h>
> #include <sys/poll.h>
> #include <gtk/gtk.h>
>
> void handle_input(gpointer data, gint source, GdkInputCondition condition)
> {
>     char buf[1024];
>     struct pollfd ufds[1];
>       
>     ufds[0].fd = source;
>     ufds[0].events = POLLIN;
>     poll(ufds, 1, 1000);
>     printf("0x%x\n", ufds[0]. revents);
>
>     buf[0] = '\0';
>     read(source, buf, 1024);
>
>     printf(buf);
> }
>
> int main(int argc, char *argv[])
> {
>     gtk_init(&argc, &argv);
>
>     (void)gdk_input_add(STDIN_FILENO, GDK_INPUT_READ, handle_input, NULL);
>
>     gtk_main();
>       
>     return 0;
> }
>
> Now, when I compile this into polltest and run it...
>
> $ echo test | ./polltest
> 0x11
> test
> 0x10
> 0x10
> 0x10
> 0x10
> 0x10
> ...
> ^C
>
> This effect appears to be freezing the GUI part of my app. I'm guessing
> that this has something to do with the changes described in this message:
>
> http://mail.gnome.org/archives/gtk-devel-list/1999-March/msg00089.html
>
> where the GDK_INPUT_* mappings were changed.
>
> My question is, is there a portable and efficient way to work around
> this?  Right now I'm calling poll() in my handler to see if stdin has a
> hangup, but this seems redundant and something that glib and/or gdk should
> handle.

This is how input watches in GDK have always worked; and how
select() works. EOF on a file descriptor is signaled by notification
that the file descriptor is ready for reading, and the following
read producing 0 bytes.

When that happens, you are responsible for closing your end
of the pipe and removing the input watch yourself.

(If you use g_io_channel_add_watch(), you will get poll() semantics
instead of select() semantics - that is, there is G_IO_HUP. However,
because poll may be emulated by select on some systems, you still
have to check for zero length reads as an indication of EOF.)

Regards,
                                        Owen