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

Hi,

I am running perl, v5.6.0 built for MSWin32-x86-multi-thread on windows 2000. I get a weird behavior when running scripts that system off large executables. After I am all done running the systemed off executable, and the script the perl.exe can still be seen in the windows Task Manager. I launch a lot of jobs remotely to different machines and for some weird reason some of these machines are accumulating these finished perl.exe in their process tables. I have nod idea if this a perl bug or windows feature (like the lost STDIN/STDOUT problem seen on win 2000). If anyone has seen this weird behavior before or knows why this could be happening please let me know

Thanks.

Replies are listed 'Best First'.
Re: Perl.exe weird behavior on windows
by JSchmitz (Canon) on Jun 10, 2002 at 17:15 UTC
    Probably the most important thing to remember when rewriting code to work with Perl.exe is data persistence. Since scripts do not "exit", all data stays in memory. If you depend on something to be empty, or filled from the results of previous code, declaring my $variable=""; in the early part of your code will clear up most data persistence errors.

    Remember that BEGIN blocks are executed only when the script is compiled, i.e., the first time you run it. This means that you can open your log files, and your data files / data connections and then leave them open until the END block is run, i.e., on server shutdown, or when the script has been run the number of times defined by the Reload registry entry.

    For the average user, Perl scripts should run with no changes. You will usually run into these issues only if the script makes assumptions about variables automatically becoming uninitialized when it is finished executing.

    When executing a script that returns a non-zero exit value, Perl.exe removes the script from its internal memory, and the script will be recompiled before it is next executed. A script that calls exit with the value "0", or with no argument, will not be removed from memory.
    Source: Activestate.com

    cheers
    JS
      jspart is right. This has nothing to do with the question. Here's the actual quote from ActiveState (emphasis mine):

      Getting your code working with PerlEx Probably the most important thing to remember when rewriting code to work with PerlEx is data persistence. Since scripts do not "exit", all data stays in memory. If you depend on something to be empty, or filled from the results of previous code, declaring my $variable=""; in the early part of your code will clear up most data persistence errors.

      See the difference between PerlEx and perl.exe? It's not even accurate after changing Ex to exe.

      How does this apply? This looks almost like mod_perl issues...

      (pause while /me searches activestate.com)

      Yep. Look at the PerlEx documentation - it seems you've mistaken 'PerlEX' (AS's web server accelerator) with 'perl.exe'

Re: Perl.exe weird behavior on windows
by talexb (Chancellor) on Jun 10, 2002 at 17:15 UTC
    It seems normal to me that if you use a Perl script to launch an application, the Perl script will continue to run until the application it has launched returns to the script. The script will then continue.

    Perhaps you want to launch a detached process instead? (I'm not sure how this is done under Windows.)

    --t. alex

    "Nyahhh (munch, munch) What's up, Doc?" --Bugs Bunny

Re: Perl.exe weird behavior on windows
by flounder99 (Friar) on Jun 10, 2002 at 19:54 UTC
    Try using exec instead of system if you don't need a return value from the other program you are running.
    Your perl.exe will be overwritten in memory by the other program.

    flounder

Re: Perl.exe weird behavior on windows
by bnh (Novice) on Jun 10, 2002 at 20:00 UTC
    well you could you try exec instead. The exec function executes a system command and never returns-- use system instead of exec if you want it to return. system does exactly the same thing as exec LIST, except that a fork is done first, and the parent process waits for the child process to complete.