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

By Stas Bekman (Send Email)
Posted Feb 27, 2001


  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 "started\n";
      # do something time-consuming
      sleep 1, warn "sh\n" for 1..20;
      warn "completed\n";

      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 "started\n";
      # do something time-consuming
      sleep 1, warn "sh\n" for 1..20;
      warn "completed\n";

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.



Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.