Your "program" is a Perl function. Can it be an independent script? If so, you could spawn a thread to act as a bridge.

use IPC::Open3 qw( open3 );

sub run_child { 
   my ($widget) = @_;

   my $pid = open3(
      my $to_child,   # Autovivified when false.
      my $fr_child,   # Autovivified when false.
      undef,          # Same as $fr_child when false.
      $somecommand,
      @args
   );

   while (<$fr_child>) {
      my $end_is_visible = ( $yview == 1.0 );
      $text->insert('end', $_);
      $w->see('end') if $end_is_visible;
   }

   waitpid($pid, 0);
}
[download]

And I have no idea how Tk will react to threads, especially when calling a $widget method from a separate thread.

Tk will react.....calling a $widget method from a separate thread

Tk will crash, you can't access widgets from threads. Gtk2 allows it, with some precautions, but not Tk.

In your example, your best bet to handle it, would be to pass the fileno of $fr_child back to the main thread thru a shared variable, then open the fileno in main, read it, and put it into the widget.

---

I'm not really a human, but I play one on earth Remember How Lucky You Are

your best bet to handle it, would be to pass the fileno of $fr_child back to the main thread

Who's gonna read from that handle? The OP wants the program to run asynchronously with the Tk window, such that output from the program gets added to the Tk window as it is produced.

Seems to me that the problem here is that you are trying to use tie *STDOUT, 'Tk::Text', $widget; in ways it simply wasn't designed to work.

Although a brief scan didn't turn up any docs for tieing TK widgets in this way, it seems pretty likely that it is intended to take the output from a separate process and pipe it into the tied widget. And under win32, with fork being just an emulation using a thread, and async being a thread, what you're actually trying to do is pipe what is written to STDOUT by one thread and read it back from another thread.

STDOUT is process global--ie. shared by all threads in the process, although different threads my have different cloned/duped handles to it--which means that you would (at least) need to some kind of synchronisation between the threads. But I see no way of providing that without digging deep into the guts of the Tk widget/tie mechanism, which from past experience is a distinctly non-trivial undertaking.

The idea of writing from your process, into a piece of system allocated memory from one thread and then reading back from that system allocated memory in another thread and expecting the "system" to successfully mediate that is just a tad optimistic :)

You have a couple of options,

1. Run your 'program' as a true separate process, (per ikegami's post), but using Win32::Process so that you can have the child process inherit the parent (Tk) process' standard handles.

   That might allow the tieing of STDOUT to a text widget to work?

2. Run your subroutine in a thread, but modify it to write to a Thread::Queue instead of STDOUT. Then set-up a Tk::after repeating timer to read from that queue and write to the text widget.

   This keeps all the Tk interaction firmly in a single (main) thread. It works! And there are several examples of it kicking around this site.

That might allow the tieing of STDOUT to a text widget to work?

You can't pass a tied handle to spawned process.

Run your subroutine in a thread, but modify it to write to a Thread::Queue instead of STDOUT. Then set-up a Tk::after repeating timer to read from that queue and write to the text widget.

That's the only solution I can think of.

Modifying the subroutine is not technically necessary. STDOUT could be tied to a module which adds to a Thread::Queue similarly to how it's currently being tied to a module that adds to the Text widget.

You can't pass a tied handle to spawned process.

A spawned process can inherit (system level) handles from it's parent. In the same way that *nix can set up pipes in the parent and arrange for them to be inherited by the forked process so that it's STDOUT is connected to it's parent STDIN and vice versa, so you can do the same thing using CreateProcess.

I can't find an documentation on this tie a handle to a widget, but it can't be entirely dissimilar under the covers. Something along the lines of this code posted a little while ago (I think an anonymonk or maybe it was tye?):

use strict;
use warnings;

my $outfile = 'ff.tmp';
my $exe     = $^X;
my @args    = (
    'perl', '-e', 'print qq{to stdout};print STDERR qq{to stderr}'
);


print "here we go, running '$exe'\n";
print STDERR "here we go to stderr\n";

 open(SAVOUT, ">&STDOUT") or die "error: save original STDOUT: $!";
 open(SAVERR, ">&STDERR") or die "error: save original STDERR: $!";
 open(STDOUT, '>', $outfile) or die "error: create  '$outfile': $!";
 open(STDERR, '>&STDOUT')    or die "error: redirect '$outfile': $!";
 system { $exe } @args;
 my $rc = $? >> 8;
 open(STDOUT, ">&SAVOUT") or die "error: restore STDOUT: $!";
 open(STDERR, ">&SAVERR") or die "error: restore STDERR: $!";
 close(SAVERR) or die "error: close SAVERR: $!";
 close(SAVOUT) or die "error: close SAVOUT: $!";

print "rc=$rc\n";
print STDERR "rc=$rc to STDERR\n";
[download]

Basically save the standard handle(s), connect it(them) to pipe(s), spawn the child with inheritance, restore the parent standard handle(s), write to/read from the pipes. It would be the parents end of the pipe connected to the childs STDOUT that you would then tie to the widget.

A simplified version which might work (but haven't had time to try), is to spawn the child using a piped open and then tie the pipe to the widget.

STDOUT could be tied to a module which adds to a Thread::Queue similarly to how it's currently being tied to a module that adds to the Text widget.

That's an interesting idea. Code could be added to Thread::Queue that inspects the mode supplied on the tie (read or write) and then tie the appropriate ends of the queue to a tied handle.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Thanx for all the help guys, sorry for the late reply...
I'm trying with the second method:

Run your subroutine in a thread, but modify it to write to a
Thread::Queue instead of STDOUT. Then set-up a
Tk::after repeating timer to read from that queue and write to the text widget.

Will get back soon

use strict;
use warnings;

use Win32::API     qw( );
use Win32API::File qw( GetOsFHandle INVALID_HANDLE_VALUE );
use Tk             qw( MainLoop );


use constant ERROR_BROKEN_PIPE => 109;


BEGIN {
   # BOOL WINAPI PeekNamedPipe(
   #    __in       HANDLE hNamedPipe,
   #    __out_opt  LPVOID lpBuffer,
   #    __in       DWORD nBufferSize,
   #    __out_opt  LPDWORD lpBytesRead,
   #    __out_opt  LPDWORD lpTotalBytesAvail,
   #    __out_opt  LPDWORD lpBytesLeftThisMessage
   # )

   my $f = Win32::API->new('kernel32', 'PeekNamedPipe', 'LPLPPP', 'L')
      or die $^E;

   sub PeekNamedPipe {
      my $vBuffer           = defined($_[1]) ? $vBuffer          : 0;
      my $nBytesRead        = defined($_[3]) ? pack('L!', $_[3]) : 0;
      my $nTotalBytesAvail  = defined($_[4]) ? pack('L!', $_[4]) : 0;
      my $nBytesLeftThisMsg = defined($_[5]) ? pack('L!', $_[5]) : 0;

      my $rv = $f->Call(
         $_[0],
         $vBuffer,
         $_[2],
         $nBytesRead,
         $nTotalBytesAvail,
         $nBytesLeftThisMsg,
      );

      $_[1] = $vBuffer                         if defined $_[1];
      $_[3] = unpack('L!', $nBytesRead       ) if defined $_[3];
      $_[4] = unpack('L!', $nTotalBytesAvail ) if defined $_[4];
      $_[5] = unpack('L!', $nBytesLeftThisMsg) if defined $_[5];

      return $rv;      
   }
}


my $mw;
my $text;
my $startb;
my $repeater;

my $count; BEGIN { $count = ''; }

my $pid;
my $fh_pipe;
my $fd_pipe;


sub start {
   $startb->configure( -state => 'disabled' );

   return if defined($pid);

   my $cmd = qq{"$^X"}
           . q{ -le"$|++;print(''.localtime),sleep(1) for 1..10"};

   $pid = open($fh_pipe, "$cmd 2>&1 |")
      or die $!;

   ( $fd_pipe = GetOsFHandle( $fh_pipe ) ) != INVALID_HANDLE_VALUE
      or die $^E;

   $count = 0;
   $repeater = $mw->repeat(10, \&poll);
}


sub stop {
   my ($force) = @_;

   undef $repeater;
   $count = '';

   kill TERM => $pid if $pid;

   undef $pid;
   undef $fd_pipe;
   undef $fh_pipe;

   $startb->configure( -state => 'normal' );
}


sub poll {
   if ( !defined($pid) ) {
      stop();
      return;
   }

   ++$count;

   my $avail = 0;
   if ( !PeekNamedPipe( $fd_pipe, undef, 0, undef, $avail, undef ) ) {
      if ( $^E == ERROR_BROKEN_PIPE ) {
         stop();
         return;
      }
      die $^E;
   }

   return if !$avail;

   sysread($fh_pipe, my $buf, $avail)
      or die $!;

   $text->PRINT($buf);
}


{
   $mw = MainWindow->new( -background => 'gray50' );
   $text = $mw->Scrolled('Text')->pack();
   $startb = $mw->Button( -text    => 'Start',
                          -command => \&start,
                        )->pack();
   my $label = $mw->Label( -textvariable => \$count
                         )->pack();
   my $stopb = $mw->Button( -text    => 'Exit',
                            -command => sub { stop(); exit(); },
                          )->pack();
   MainLoop();
}
[download]

Update: Simplified the code slightly by using the code from Re^8: ... (Proof!) instead of the code from Re^2: Non-blocking Reads from Pipe Filehandle.

A valuable script/model for Tk/Win32 users, thanks for posting that.

---

I'm not really a human, but I play one on earth Remember How Lucky You Are

So.... just another reason to consider Glib and Gtk2 for your next Win32 project.

So.... just another reason to consider Glib and Gtk2 for your next Win32 project.

Don't you consider that recommending the download and installation of 15MB of Gimp and 23MB of Gtk2 is a bit extreme for a problem that can be solved with 10 lines of code with an out-of-the-box perl?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Well to get the Glib functionality we are talking about, only requires the most basic Glib lib, which is only a 1.5 Meg download, at Glib for Windows And that simple download will make the code shown by ikegami at Re: Please suggest a non-forking way to do this (OS: windows) (solution) seem way too complex.

Glib gives you a nice event loop and select on pipes, with a simple syntax, and is cross-platform. With Glib you can write the same pipe-open code for linux and win32, whearas Win32 modules are single platform.

To be honest, that is far less than all the f*cking vb dlls you need to download to make most of that win32 crap run. No wonder the minimal space required for a Vista install is 20 gigs.

Don't you consider that recommending the installation of 20 gigs of virus prone win32 crap a bit extreme for a problem that can be solved with 1 gig linux box? :-)

---

I'm not really a human, but I play one on earth Remember How Lucky You Are