in reply to How to deal with a forked proces that is waiting for user input?

See Re^13: Forking Clients


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."
  • Comment on Re: How to deal with a forked proces that is waiting for user input?

Replies are listed 'Best First'.
Re^2: How to deal with a forked proces that is waiting for user input?
by gepapa (Acolyte) on Oct 21, 2008 at 19:26 UTC

    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; }

    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?

Re^2: How to deal with a forked proces that is waiting for user input?
by gepapa (Acolyte) on Oct 21, 2008 at 19:37 UTC

    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; } }

    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>;

      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.

        Thanks for the feedback.

        In the is_joinable check I had attempted to try both join and detach, but in both cases it causes the script to crash perl. If I run it as is I see:

        Perl exited with active threads: 0 running and unjoined 1 finished and unjoined 0 running and detached
        At the end of the run, which is what you had mentioned. I would love to join it but I just don't know why it keeps crashing my perl(Activestate 5.8.8 32 bit on Windows)

        I want to be able to access the information in @results, after the _timedCommand has returned. When running the diskpart system call, a few lines of information are printed prior to the point where it asks for user input, it is these lines I would like to get back. I will try the queue and see if that does what I need it to do.

        Thanks.

        I updated my code to reflect more where I am currently at.

        Here is my latest 2 implementations. They both allow me to detach the thread without a hang. Only the first one gets back the information even in the case of it waiting for user input. But I am not sure if either is exactly thread safe, and I am not sure I am using the thread queue as you intended. But this was the way I could get it working.

        Implementation 1:

        my $queue = new Thread::Queue; my $command = 'diskpart'; my $status = _timedCommand($command, 90); if ($status eq 'TIMEOUT') { print "\n=======TIMEOUT==========\n"; } my @ans; while (my $ref = $queue->dequeue_nb()) { if (ref($ref) =~ m/ARRAY/i) { push(@ans, @$ref); } else { push(@ans, $ref); } } print "@ans\n"; sub _timedCommand { my ($command, $time) = @_; my $pid :shared; my @tmp :shared; my $thr = async { $pid = open my $fh, "$command |" or die "$!"; push @tmp, $_ while <$fh>; $fh->close(); }; while ($thr->is_running() and $time > 0) { sleep(1); $time--; } if ($thr->is_joinable()) { $thr->detach(); $queue->enqueue(\@tmp); return 'OK'; } else { $thr->detach; kill 3, $pid; $queue->enqueue(\@tmp); return 'TIMEOUT'; } }

        Implementation 2:

        my $queue = new Thread::Queue; my $command = 'diskpart'; my $status = _timedCommand($command, 90); if ($status eq 'TIMEOUT') { print "\n=======TIMEOUT==========\n"; } my @ans; while (my $ref = $queue->dequeue_nb()) { if (ref($ref) =~ m/ARRAY/i) { push(@ans, @$ref); } else { push(@ans, $ref); } } print "@ans\n"; sub _timedCommand { my ($command, $time) = @_; my $pid :shared; my $thr = async { $pid = open my $fh, "$command |" or die "$!"; my @tmp :shared; push @tmp, $_ while <$fh>; $queue->enqueue(\@tmp); $fh->close(); }; while ($thr->is_running() and $time > 0) { sleep(1); $time--; } if ($thr->is_joinable()) { $thr->detach(); return 'OK'; } else { $thr->detach; kill 3, $pid; return 'TIMEOUT'; } }

        In the second implementation I am seeing some wonky stuff when running the diskpart command, at times it @ans is populated and it prints out information, at other times it is not and doesn't. I have to assume its a timing issue, but I am not sure where it would be. For a dir command it works as expected.

        Output from Implementation 1:

        C:\Sandbox>perl ForkProcessTimeout.pl =======TIMEOUT========== Microsoft DiskPart version 5.1.3565 Copyright (C) 1999-2003 Microsoft Corporation. On computer: USITPAPADGD1C DISKPART>

        Output from Implementation 2:

        The output is inconsistent:

        C:\Sandbox>perl ForkProcessTimeout.pl =======TIMEOUT========== Microsoft DiskPart version 5.1.3565 Copyright (C) 1999-2003 Microsoft Corporation. On computer: USITPAPADGD1C DISKPART> C:\Sandbox>perl ForkProcessTimeout.pl =======TIMEOUT========== C:\Sandbox>perl ForkProcessTimeout.pl =======TIMEOUT========== Microsoft DiskPart version 5.1.3565 Copyright (C) 1999-2003 Microsoft Corporation. On computer: USITPAPADGD1C DISKPART>

        I think implementation 2 is the way I need to go for it to be threadsafe, but I don't get the consistency in output. Also when I run implementation 2 in the debugger it seems to consistently include the output.