in reply to Re: Please suggest a non-forking way to do this (OS: windows)
in thread Please suggest a non-forking way to do this (OS: windows)

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.

  • Comment on Re^2: Please suggest a non-forking way to do this (OS: windows)

Replies are listed 'Best First'.
Re^3: Please suggest a non-forking way to do this (OS: windows)
by BrowserUk (Patriarch) on Sep 29, 2008 at 22:08 UTC
    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.
[reply]
[d/l]

      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.

[reply]
[reply]

In Section Seekers of Perl Wisdom