Re: gtkmm Monitoring IO example

[Andrew Potter <agpotter gmail com>]

On Fri, Sep 25, 2015 at 8:02 AM, Chris Vine <chris cvine freeserve co uk> wrote:
> On Fri, 25 Sep 2015 15:13:48 +0200
> Kjell Ahlstedt <kjell ahlstedt bredband net> wrote:
> > When I tested the input example program on my dual-core PC, I got the
> > same result: The CPU load on one of the cores is 100% after something
> > is written to the fifo. Most of the relevant code is in glib. I don't
> > know all details, but this is what I found:
> >
> > Before anything is written to the fifo, the program waits at
> >     read_fd = open("testfifo", O_RDONLY);
> > without using much CPU time (perhaps no time at all).
> > Once the fifo contains data to read, open() returns, and the program
> > enters the main loop at
> >     app->run();
>
> Assuming we are talking about a unix-like system, it certainly isn't.
> glib will either call poll() or select() and block in a separate i/o
> thread, and I think it is poll() which it uses.  Neither should busy
> wait, assuming the waiting input is correctly extracted from the file
> descriptor which has become ready.

The problem is that there is an Glib::IO_HUP event constantly
generated on the fifo once the first writer disconnects (the first
echo).

I guess this stackoverflow answer describes the problem:
https://stackoverflow.com/questions/22021253/poll-on-named-pipe-returns-with-pollhup-constantly-and-immediately

So basically glib's call to poll() is always returning immediately
because it is sensitive to IO_HUP. I can't find an obvious way to make
it insensitive to this signal.