See Re^13: Forking Clients

Hi Browser, thanks for the link. I tried this but Perl is crashing when I run it.

Here is my code:

my $command = 'dir';

my (@results) = _timedCommand($command, 30);

if (@results) {
    print "Good:\n " . join(' ', @results);
}
else {
    print "Bad\n";
}


sub _timedCommand
{
    use threads;
    use threads::shared;

    my ($command, $time) = @_;

    my @results :shared;
    my $pid :shared;

    async {
        $pid = open my $fh, "$command |" or die "$+, $^E";
        @results = <$fh>;
        $fh->close();
    }->detach;

    kill 0, $pid while sleep 1 and $time--;
    kill 3, $pid and return if $time;

    return @results;
}
[download]

As you can see I tried testing it with a simple dir command which shouldn't cause any issues. When I put it in the debugger, it gets to the return statement, and @results is fine, once I execute the return line it simply kicks out of the debugger.

Any ideas why it would do that?

I made some changes to your basic code structure and came up with something that gets me almost there. Could you take a look and let me know if you see any glaring issues.

Also I assumed the way I have it coded would enable me to get whatever was "printed" prior to killing the thread but this does not seem to be the case, any ideas on what I am doing wrong?

UPDATED:

my $command = 'diskpart';

my (@results) = _timedCommand($command, 30);

my $last = pop(@results);
if ($last =~ m/^!!!TIMEOUT!!!/i) {
    print "Bad: \n" . join(' ', @results);
}
else {
    push(@results, $last);
    print "Good:\n " . join(' ', @results);
}


sub _timedCommand
{
    use threads;
    use threads::shared;

    my ($command, $time) = @_;

    my @results :shared;
    my $pid :shared;

    my $thr = async {
        $pid = open my $fh, "$command |" or die "$!";
        @results = <$fh>;
        $fh->close();
    };

    while ($thr->is_running() and $time > 0) {
        sleep(1);
        $time--;
    }
    if ($thr->is_joinable()) {
        return @results;
    }
    else {
        $thr->detach;
        kill 3, $pid;
        push(@results, '!!!TIMEOUT!!!');
        print ("\n @results \n");
        return @results;
    }
}
[download]

Thanks

Could you take a look and let me know if you see any glaring issues.

This is iffy: or die "$+, $^E";.

You probably mean $! not $+, and $^E probably won't give you anything unless you are running under windows (or maybe OS/2?).

And you are testing if the thread is joinable, but never joining (or detaching) it. Which means it will hang around until the program ends. At which point you would probably get a warning message.

Also I assumed the way I have it coded would enable me to get whatever was "printed" prior to killing the thread but this does not seem to be the case, any ideas on what I am doing wrong?

I'm not really sure I understand what you mean by that? Exactly where in your code do you want to access it?

You should certainly be able to access the contents of the shared array @result from outside the thread whilst the command is still running. But probably not the way you have it coded currently:

@results = <$fh>;
[download]

Perl probably locks the entire array until that statement completes, which won't be until the command completes. If you changed that to push @results, $_ while <$fh>; you might have more success, but remember that you would have to employ locking to prevent conflicts.

Perhaps a better way would be to use a Thread::Queue which is basically just a shared array and a couple of simple methods (or was until they f***ed with it recently!), but it does take care of the locking for you which is a great convenience, as you know it is done right.

However, since timedCommand() can't return anything until you've cleaned up the process and thread, it is hard to see what benefit you would get from that?

---

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

Since this is an issue, I assume that the program will be run without a person sitting there watching it, correct?

Also, I'm guessing that the forked processes will sometimes be run by a human directly and may then require user input, but sometimes will be run by your program, and for whatever reason will be able to function properly without receiving any input in that case.

If my assumption and my guess are correct, then why not add a command line argument to the program that gets forked? Wrap the sections that get user input in an 'if' and just skip over that section if the command line argument has been set. That way you can fork it without having it hang by passing the correct argument, and it will still work as usual if invoked directly from the command line.

It's not particularly fancy or elegant, but it's simple and should work unless there's constraints I'm not aware of

This will always be run via automation, so no user input.

Ohhh, I get it now. For some reason I thought that by 'processes' you were referring to stuff you had developed and were calling; upon re-reading your node I see that I was mistaken.