On Fri, Sep 25, 2015 at 8:02 AM, Chris Vine <[email protected]> wrote: > On Fri, 25 Sep 2015 15:13:48 +0200 > Kjell Ahlstedt <[email protected]> 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. _______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
