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.
Kjell
Den 2015-09-25 kl. 08:04, skrev Sanne Ausma:
I am trying the Gtkmm Monitoring I/O example from the gtkmm-tutorial.
(https://developer.gnome.org/gtkmm-tutorial/unstable/sec-monitoring-io.html.en)
The example works but after something has been written to the fifo,
top shows the CPU load going to 100%.
I have tried the example with both gtkmm 3.0 and 2.4 but the result is
the same.
Is this normal behaviour?
Thanks,
Sanne
_______________________________________________
_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
