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(); > After that, the fifo is monitored by polling. Polling is inefficient. > Probably it's the only possible way that the OS offers. It does seem > a bit extreme to use all available CPU time for polling, but probably > it's normal behaviour.
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. I suspect there is something wrong with the example code, possibly to do with the way Glib::IOChannel is used with the version of Glib::SignalIO::connect() which takes a file descriptor rather than the IOChannel object itself - it would be worth trying the version of Glib::signal_io().connect which takes the IOChannel object. Possibly something goes amiss if you don't do that, but that's a guess. As an aside, I have always found Glib::IOChannel and GIOChannel quite difficult to use and I avoid them. The Gio namespace offers better functionality. Where Glib::SignalIO::connect() comes into use is if you have a raw file descriptor which you want to read when it comes available using something like unix read(): then, the version of Glib::SignalIO::connect() which takes a descriptor can be very useful. Chris _______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
