Re: CPU load increasing with IO watch

[muppet <scott asofyet org>]

On Jan 24, 2007, at 6:16 PM, Mike Martin wrote:

> I have the following code using IO watch
> open($file, "-|","$prog $inp1 $opts $newfile  2>&1" );
> my $end_mark=$buffer->create_mark('end',$buffer->get_end_iter,0);
> our $tag=  Glib::IO->add_watch ( fileno($file), ['in', 'hup'], sub {
>           my ($fileno, $condition,$tag) = @_;
>           if ($condition eq 'hup') {
>
>                   close $file;
>                   return 0;  # uninstall
>           }
or "close and uninstall if condition is 'hup'".  You don't want to do  
this first.  Place the check for "hup" *last* in the handler.   
$condition can contain *both* 'in' and 'hup' in the same invocation,  
and if you do the hang-up first, you will discard that final chunk of  
data.

>           my $line ;
>           sysread $file, $line, 256;
>           my $start=$buffer->get_iter_at_line(25);
>           my $endline;
>           if ($buffer->get_line_count() >34){
>                   $endline=$buffer->get_line_count()-10;
>           }
>           else {$endline=$buffer->get_line_count()};
>
>           my $end=$buffer->get_iter_at_line($endline);
>
>           $buffer->signal_connect(insert_text=>sub{
>                   $textview->scroll_to_mark($end_mark, 
> 0.0,1,0.0,1.0);});
This signal_connect() call belongs outside of the handler, where you  
create $buffer.  With the call in here in the io watch handler, you  
will install another signal handler on the buffer every time the  
watch handler is invoked.  The way this is written, after 100  
callbacks to the watch handler, the $buffer will invoke each and  
every one of the 100 closures you've attached to its insert_text  
signal.  This takes memory and time and will cause your program to  
run slower and hog more resources.
>           if ($endline >34){
>                   $buffer->delete($start,$end);
>           }
>           $buffer->insert($buffer->get_end_iter, $line);
>           #$buffer->set_text($line);
>           sleep 10;
Never, ever sleep() in an event-driven program, especially not for  
ten seconds.  This causes your IO watch to block the main loop,  
meaning your UI becomes unresponsive and a large number of  
unprocessed events pile up.  You even run the risk of losing data on  
sockets or causing the other end of the pipe to block until there is  
room available for writing.
>           return 1;
>   }
> );
>
> The problem I have is that as the watch progresses CPU load for the
> watch increases at the expense of external program being run.
Try fixing the issues i mentioned above, and see if you still have  
these problems.


--
Doing a good job around here is like wetting your pants in a dark  
suit; you get a warm feeling, but no one notices.
  -- unknown