Dirk80 has asked for the wisdom of the Perl Monks concerning the following question:

Again a process question from me. I'm very interested in this topic and I do a lot of experiments to learn more about it.

Now my goal is it to kill, suspend and resume a process from a TK GUI in Windows XP.

Again I was inspired from the Code of BrowserUK from this thread: http://www.perlmonks.org/?node_id=470827

First the code of the child process.

child.pl:

use strict; use warnings; $|=1; print "$_\n" and select(undef,undef,undef,0.1) for 1 .. 1000;

Here the code of the father process which is using open to let the child process run.

father_open.pl

#!perl -slw use strict; use threads; use threads::shared; use Thread::Queue; ## A shared var to communicate progess between work thread and TK my $Q = new Thread::Queue; my $pid:shared; sub work{ $pid = open (CHILD_PROC, "perl child.pl |") or die $!; while( <CHILD_PROC> ) { $Q->enqueue( $_ ); } close( CHILD_PROC ); } threads->new( \&work )->detach; use Tk; use Tk::ProgressBar; my $mw = MainWindow->new; my $pb = $mw->ProgressBar()->pack(); my $repeat; $repeat = $mw->repeat( 100 => sub { while( $Q->pending ) { my $progress = $Q->dequeue; return unless $progress; $repeat->cancel if $progress == 100; $pb->value( $progress ) } } ); $mw->Button('-text' => 'Cancel', '-command' => sub{ kill 9, $pid; exit(0); })->pack(); # No suspend and kill button because # the signals SIGSTOP and SIGCONT do not exist for Windows $mw->MainLoop;

This code starts the child process sucessfully and it is possible to kill the child process. But I did NOT know how to supsend or resume the child process because after googling I had the knowledge that the signals SIGSTOP and SIGCONT do NOT exist for a Windows OS.

That's why I continued looking in google, CPAN, PerlMonks,... . So I found the Win32::Process module which allows it to suspend and resume a process.

Here you see the code of the father process using Win32::Process instead of open.

father_win32_process.pl

#!perl -slw use strict; use threads; use threads::shared; use Thread::Queue; use Win32::Process; use Win32; use Data::Dumper; sub ErrorReport { print Win32::FormatMessage( Win32::GetLastError() ); } ## A shared var to communicate progess between work thread and TK my $Q = new Thread::Queue; my $ProcessObj_as_string:shared; my $ProcessObj; sub work{ # save STDOUT open(my $STDOUT_ORIG, ">&", \*STDOUT) or die; # connect TO_CHILD_PROC with CHILD_PROC pipe(CHILD_PROC, TO_CHILD_PROC); # change STDOUT to TO_CHILD_PROC # --> STDOUT of child process is set to TO_CHILD_PROC and # this is connected via pipe with CHILD_PROC open(STDOUT, ">&", \*TO_CHILD_PROC); Win32::Process::Create($ProcessObj, "C:\\Perl\\bin\\perl.exe", "perl child.pl", 1, NORMAL_PRIORITY_CLASS, ".")|| die ErrorReport(); $ProcessObj_as_string = Dumper($ProcessObj); # restore STDOUT open(STDOUT, ">&", $STDOUT_ORIG) or die; while( <CHILD_PROC> ) { chomp($_); $Q->enqueue( $_ ); } close( CHILD_PROC ); } threads->new( \&work )->detach; use Tk; use Tk::ProgressBar; my $mw = MainWindow->new; my $pb = $mw->ProgressBar()->pack(); my $repeat; $repeat = $mw->repeat( 100 => sub { while( $Q->pending ) { my $progress = $Q->dequeue; return unless $progress; $repeat->cancel if $progress == 100; $pb->value( $progress ); } } ); $mw->Button('-text' => 'Cancel', '-command' => sub { my $VAR1; $ProcessObj = eval($ProcessObj_as_string); $ProcessObj->Kill(0); exit 0; })->pack(); $mw->Button('-text' => 'Suspend', '-command' => sub { my $VAR1; $ProcessObj = eval($ProcessObj_as_string); $ProcessObj->Suspend(); })->pack(); $mw->Button('-text' => 'Resume', '-command' => sub { my $VAR1; $ProcessObj = eval($ProcessObj_as_string); $ProcessObj->Resume(); })->pack(); $mw->MainLoop;

This code is also able to start successfully the child process and the child process can successfully be killed. It is also possible to suspend the child process. But afterwards it is NOT possible to resume it.

What am I doing wrong? Why is the suspending/resuming functionality NOT working properly in my code?

Is there perhaps any other solution to achieve my goal to kill/suspend/resume a process from a TK GUI in Windows?

Thank you very much!

Replies are listed 'Best First'.
Re: Suspend/Resume a process from Tk GUI in Windows XP
by BrowserUk (Patriarch) on Feb 18, 2011 at 16:01 UTC

    This works! The only real change I've made is to ensure that the 'destringification' of the process object only happens once:

    $ProcessObj ||= eval($ProcessObj_as_string);

    Why it works is still something of a mystery to me, but maybe it will help you forward with your investigations.

    #!perl -slw use strict; use threads; use threads::shared; use Thread::Queue; use Win32::Process; use Win32; use Data::Dumper; sub ErrorReport { print Win32::FormatMessage( Win32::GetLastError() ); + } ## A shared var to communicate progess between work thread and TK my $Q = new Thread::Queue; my $ProcessObj_as_string:shared; my $ProcessObj; sub work{ # save STDOUT open(my $STDOUT_ORIG, ">&", \*STDOUT) or die; # connect TO_CHILD_PROC with CHILD_PROC pipe(CHILD_PROC, TO_CHILD_PROC); # change STDOUT to TO_CHILD_PROC # --> STDOUT of child process is set to TO_CHILD_PROC and # this is connected via pipe with CHILD_PROC open(STDOUT, ">&", \*TO_CHILD_PROC); Win32::Process::Create( $ProcessObj, "C:\\Perl32\\bin\\perl.exe", "perl child.pl", 1, NORMAL_PRIORITY_CLASS, "." )|| die "$! : $^E"; warn "$ProcessObj $$ProcessObj"; $ProcessObj_as_string = Dumper($ProcessObj); # restore STDOUT open(STDOUT, ">&", $STDOUT_ORIG) or die; while( <CHILD_PROC> ) { chomp($_); $Q->enqueue( $_ ); } close( CHILD_PROC ); } threads->new( \&work )->detach; use Tk; use Tk::ProgressBar; my $mw = MainWindow->new; my $pb = $mw->ProgressBar()->pack(); my $repeat; $repeat = $mw->repeat( 100 => sub { while( $Q->pending ) { my $progress = $Q->dequeue; return unless $progress; $repeat->cancel if $progress == 100; $pb->value( $progress ); } } ); $mw->Button( '-text' => 'Cancel', '-command' => sub { my $VAR1; $ProcessObj ||= eval($ProcessObj_as_string); warn "$ProcessObj $$ProcessObj"; $ProcessObj->Kill(0); exit 0; } )->pack(); $mw->Button( '-text' => 'Suspend', '-command' => sub { my $VAR1; $ProcessObj ||= eval($ProcessObj_as_string); warn "$ProcessObj $$ProcessObj"; $ProcessObj->Suspend(); } )->pack(); $mw->Button( '-text' => 'Resume', '-command' => sub { my $VAR1; $ProcessObj ||= eval($ProcessObj_as_string); warn "$ProcessObj $$ProcessObj"; $ProcessObj->Resume(); } )->pack(); $mw->MainLoop;
    To understand why I tried it, try running your original code, but immediately suspend the child using the Process Explorer, then you'll find that the resume will work via your Tk interface. Exactly once.

    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.

      Thank you a lot. This really solved the problem. And thank you for the recommendation of the Process Explorer.

      Why is it a mystery for you that it is working?

        Why is it a mystery for you that it is working?

        Because you are effectively sharing an object between threads which was never designed to work. This is evidenced by the fact that if you try to make $ProcessObj a shared variable so that you could use it directly from other threads, you get an error message along the lines of:

        Invalid value for shared scalar at ...

        You've bypassed this design restriction by stringifying the object handle Win32::Process=SCALAR(0x3e820f0) into a shared variable and then string evaling it back into existence in the other thread:$ProcessObj = eval($ProcessObj_as_string).

        The problem you had is that this only worked once. What my 'fix' does is avoid it being done multiple times. But the fact that it is not repeatable, means that it works by chance, rather than by design. Indeed, the design was to explicitly prevent it.

        In fact the only reason it does work once for this particular object is because the object is a simple blessed scalar reference that contains a process-wide OS handle--which is just a number.

        If the object contained any perlish state--that is, any perl instance variables--it wouldn't work.

        Basically, you got something to work through sheer luck, but you shouldn't rely upon it for anything remotely serious.


        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.