3

My question is as simple as what the zenity --text args say in the example... but what is causing this 100% CPU grab by the redirection?
...(and by the way, is this particular usage of < actually called redirection. It seems like it is creating a direction, rather than re-directing ).. 

echo "Peacocks talking of the colour grey."> test cat test | zenity --text='This does NOT hog the CPU' --list --column='#' --width=450 <test zenity --text='This hogs 100% of CPU usage' --list --column='#' --width=450  

I'm quite happy to use cat test | (because it isn't useless in this case; it works and < and | are somehow different, but I haven't been able to track it down again...

To be clear: <test and cat test | both work. The zenity dialog appears and is fully functional in both cases, but for as long as the <test version of the dialog is kept open, it uses 100% CPU (of one core)... 94% on the single "core" VMs...

Improve this question
2
  • As long as test file exists, I do not see any difference. Commented Jul 16, 2011 at 3:38
  • I've tried in Ubuntu 10.04, 10.10 and 11.04.. The same thing happens in all of them... (10.10, and 11.04, are recently installed and updated VirtualBox guest VMs. The host is 10.04 Commented Jul 16, 2011 at 4:13

2 Answers 2

Reset to default
5

It looks like a bug in zenity. You can see what is going on by using the strace tool (I've wrapped the strace lines in this post to make it easier to read).

With the pipe version, this line in strace shows what happens when the pipe is closed (because cat exits):

poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=0, events=POLLIN}], \ 3, 0) = 1 ([{fd=0, revents=POLLIN|POLLHUP}])

That part at the end - fd=0, revents=POLLIN|POLLHUP, in particular POLLHUP - tells zenity that stdin has hung up (writer of the pipe has gone away). Zenity is processing this correctly and closing fd 0 later.

Files do not get POLLHUP events - instead a read(2) result of zero means EOF. This is a different code path for zenity. It polls again for fd 0 and this is what it gets:

poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=0, events=POLLIN}],\ 3, 0) = 1 ([{fd=0, revents=POLLIN}]) read(0, "", 1024) = 0

That should be the end of it - the zero read should cause zenity to close fd 0. But it doesn't. The strace output above keeps repeating, as zenity keeps polling fd 0. Until fd 0 is closed, it will always be ready for reading, as that is how file descriptors at EOF work, since you need to read it to get the EOF result.

Because zenity is not responding correctly to EOF on stdin, it keeps looping on a poll(2)/read(2) loop, where poll returns immediately, as does read. Again, and again and again...

Improve this answer
1
  • @camh: Wow!... That is some awsome super-sleuthing... I initially couldn't quite understand your explanation, but then something gelled when I read Caleb's comment of, "sending the data as a stdin pipe vs passing a file descriptor"... Your explanation became crystal clear!... (so, in summary, I this means: don't use <file with zeinty, but piping data to it is fine)... Thanks, from a happy camper :)... Commented Jul 16, 2011 at 18:38
0

Try this:

zenity --text='This does NOT hog the CPU' --list --column='#' --width=450 <(cat test)
Improve this answer
2
  • It doesn't hog the CPU, but it also doesn't display the contents of of 'test'. It displays /dev/fd/63 instead... but sed -n p <(cat test) works fine.. it outputs the correct text... Maybe it is just a zenity thing, but I'd still like to know what the diffeence is between '<test' and 'cat test |' that zenity is having problems with. Commented Jul 16, 2011 at 4:54
  • This answer should have no effect on the bug, zenity would see this the same as <test. The difference is in sending the data as a stdin pipe vs passing a file descriptor to be opened and read by the program. Commented Jul 16, 2011 at 15:02

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.