in reply to Perl/Tk App and Interprocess Communication

The following demonstrates a Tk app that updates the screen in response to the output from another Perl process in real time: 

#!perl -slw
use strict;
use threads;
use threads::shared;

## A shared var to communicate progress between work thread and TK
my $progress : shared = 0;

sub work{
    open PROC, 
      'perl -le"$|=1; print and select(undef,undef,undef,0.1) for 1 ..
+ 1000" |'
        or die $!;
    while( <PROC> ) {
        lock $progress;
        $progress = $_;
    }
    close PROC;
}

threads->new( \&work )->detach;

require Tk::ProgressBar;

my $mw = MainWindow->new;
my $pb = $mw->ProgressBar()->pack();

my $repeat;
$repeat = $mw->repeat( 100 => sub {
#    print $progress;
    $repeat->cancel if $progress == 100;
    $pb->value( $progress ) }
);


$mw->MainLoop;

[download]
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

Replies are listed 'Best First'.
Re^2: Perl/Tk App and Interprocess Communication
by beretboy (Chaplain) on Jun 30, 2005 at 15:03 UTC
    Thanks for taking the time to write that, you've saved me a huge headache. UPDATE: I've never worked with threads in perl, could you point me towards some resources dealing with that? UPDATE UPDATE: Reading Camel Book chapter now, nevermind. Thanks again! UPDATE UPDATE UPDATE: Okay, I'd really appreciate a walkthrough of how this works, and how you can prevent it from "missing" data. If I bump the timer up to 1 second it jumps over big swaths of numbers.


    "Sanity is the playground of the unimaginative" -Unknown
[reply]

      Okay. The code I posted will miss intermediate values if the incoming values arrive faster than the screen update checks for them.

      If your application need to reflect every change, and if it can update the screen as fast or faster than the input arrives, that would not occur.

      If you cannot update the screen as fast as the input arrives, then eventually you will have to either combine multiple inputs into a single update, or discard intermediates.

      Either way, to ensure than your update thread sees all the inputs, it must either run faster than the inputs arrive, or they must be queued

      Here is a queued solution. 

      #!perl -slw
use strict;
use threads qw[ async ];
use Thread::Queue;

## A shared var to communicate progess between work thread and TK
my $Q = new Thread::Queue;

sub work{
    open PROC, 
    'perl -le"$|=1; print and select(undef,undef,undef,0.1) for 1 .. 1
+000" |'
        or die $!;
    while( <PROC> ) {
        $Q->enqueue( $_ );
    }
    close PROC;
}

threads->new( \&work )->detach;

## For lowest memory consumption require (not use)
## Tk::* after you've started the work thread.
require Tk::ProgressBar;

my $mw = MainWindow->new;
my $pb = $mw->ProgressBar()->pack();

my $repeat;
$repeat = $mw->repeat( 100 => sub {
    while( $Q->pending ) {
        my $progress = $Q->dequeue;
        return unless $progress;
        $repeat->cancel if $progress == 100;
        $pb->value( $progress )
    }
} );


$mw->MainLoop;

      [download]
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
[reply]
[d/l]

In Section Seekers of Perl Wisdom