Improving mod_perl Driven Site’s Performance — Part VI: Forking and Executing Subprocesses from mod_perl Page 5

  proper_fork1.pl
  ---------------
  use strict;
  use POSIX 'setsid';
  use Apache::SubProcess;

  my  = shift;
  ->send_http_header("text/plain");
  {CHLD} = 'IGNORE';
  defined (my  = fork) or die "Cannot fork: n";
  if () {
    print "Parent 25481 has finished, kid's PID: n";
  } else {
      ->cleanup_for_exec(); # untie the socket
      chdir '/'                or die "Can't chdir to /: ";
      open STDIN, '/dev/null'  or die "Can't read /dev/null: ";
      open STDOUT, '>/dev/null'
          or die "Can't write to /dev/null: ";
      open STDERR, '>/tmp/log' or die "Can't write to /tmp/log: ";
      setsid or die "Can't start a new session: ";
      select STDERR;
      local $| = 1;
      warn "startedn";
      # do something time-consuming
      sleep 1, warn "shn" for 1..20;
      warn "completedn";
      CORE::exit(0); # terminate the process
  }

The script starts with the usual declaration of the strict mode,

loading the POSIX and Apache::SubProcess modules and importing

of the setsid() symbol from the POSIX package.

The HTTP header is sent next, with the Content-type of

text/plain. It gets ready to ignore the child, to avoid zombies

and the fork is called.

The program gets its personality split after fork. And the if

conditional evaluates to a true value for the parent process and to a

false value for the child process, therefore the first block is

executed by the parent and the second by the child.

The parent process announces his PID and the PID of the spawned

process and finishes its block. If there will be any code outside it

will be executed by the parent as well.

The child process starts its code by disconnecting from the socket,

changing its current directory to /, opening the STDIN and STDOUT

streams to /dev/null, which in effect closes them both before

opening. In fact, in this example we don't need either of these, so I

could just close() both. The child process completes its disengagement

from the parent process by opening the STDERR stream to /tmp/log,

so it could write there, and creating a new session with help of

setsid(). Now the child process has nothing to do with the parent

process and can do the actual processing that it has to do. In our

example it performs a simple series of warnings, which are logged into

/tmp/log:

      select STDERR;
      local $|=1;
      warn "startedn";
      # do something time-consuming
      sleep 1, warn "shn" for 1..20;
      warn "completedn";

The localized setting of $|=1 is there, so we can see the output

generated by the program immediately. In fact it's not required when

the output is generated by warn().

Finally the child process terminates by calling:
      CORE::exit(0);

which makes sure that it won't get out of the block and run some code

that it's not supposed to run.