Servers Improving mod_perl Driven Site's Performance -- Part VI: Forking and Executing Subprocesses...

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.

Latest Posts

Related Stories