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."

A spawned process can inherit (system level) handles from it's parent.

Agreed. I didn't say otherwise.

It would be the parents end of the pipe connected to the childs STDOUT that you would then tie to the widget.

It's either tied or the "parent's end of the pipe". It can't be both.