On Feb 23, 2007, at 12:25 PM, Jeffrey Ratcliffe wrote:
A user running FreeBSD has reported a bug that I can't personally reproduce in my gtk2-perl application. With his help, however, I have distilled it down to the attached demo. He reports that the progress bar pulses for three seconds, then CPU usage goes up to 100% and stays there.I take it, therefore, that the Glib::IO->add_watch call isn't uninstalling itself properly. On my Ubuntu Edgy and Red Hat boxes, it runs OK, i.e. after pressing the button, the progress bar pulses for three seconds and then stops.
That's how it behaves for me on FC2 with glib 2.4.8 and Glib 1.080. (Yes, i haven't updated the stock copies in a while. ;-)
Am I doing something wrong?
The only thing i see is that you handle 'hup' before checking for 'in'. It *is* possible to get both conditions in the same callback. However, this would only result in losing the last chunk of input, not a hang.
Or is there some problem with Glib::IO->add_watch under FreeBSD?
That's quite possible, though i think it's more likely that it would be with either glib's main loop or with perl's signal handling. I don't have a FreeBSD box at my disposal for testing. Anyone?
In an attempt to rule out perl or gtk2-perl, attached is a quick port of your demo to C. The comment on the first line contains the command needed to compile it. Please have your user compile and run this and report the behavior.
Attachment:
iowatch.c
Description: Binary data
(For those playing along, i've mostly left the original perl code in comments next to the C version. It may interest you to see what level of pain you're missing by using gtk+ in perl, and how similar the C and Perl versions of the APIs really are. :-)
--If the monkey could type one keystroke every nanosecond, the expected waiting time until the monkey types out Hamlet is so long that the estimated age of the universe is insignificant by comparison ... this is not a practical method for writing plays.
-- Gian-Carlo Rota