GNOME Bugzilla – Bug 541001
"zenity --list" uses 100% CPU when given a partial line
Last modified: 2011-07-08 15:02:52 UTC
Please describe the problem: When a partial line is piped to "zenity --list", zenity uses 100% CPU until the rest of the line arrives. The same problem occurs with "zenity --progress". Steps to reproduce: 1. (echo -n 'Hello'; sleep 15; echo ' world!') | zenity --list --column=Message Actual results: Zenity uses 100% CPU during the 15-second sleep. Expected results: Zenity uses a reasonable amount of CPU. Does this happen every time? Yes. Other information: When the stdin channel buffer contains a partial line and no more input is currently available, zenity enters a tight loop of g_io_channel_read_line_string (which returns immediately with G_IO_STATUS_AGAIN) and processing any events. With attachment 113739 [details] [review], the situation is similar: zenity_util_stdin_io_func keeps returning due to the G_IO_STATUS_AGAIN and being called again because there is data in the buffer. There's no good way to fix this without an enhancement to glib, as requested by bug 126266.
See also #510496
Okay, this will sound very, very weird, however, I was able to fix this only using g_usleep(10000) (10000 was a random number) here in the loop: do { status = g_io_channel_read_line_string (channel, string, NULL, &error); while (gtk_events_pending ()) gtk_main_iteration (); g_usleep(10000); } while (status == G_IO_STATUS_AGAIN); I check my system monitor, and i got 0% cpu all time. I also check the same script with sleep 60 and got the same result: (echo -n 'Hello'; sleep 60; echo ' world!') | zenity --list --column=Message The same occur with sleep 5, 10, 30 Luis, what do you think?
Fixed on master