Apache2::SubProcess provides the Perl API for running and
communicating with processes spawned from mod_perl handlers.

At the moment it's possible to spawn only external program in a new
process. It's possible to provide other interfaces, e.g. executing a
sub-routine reference (via B::Deparse) and may be spawn a new
program in a thread (since the APR api includes API for spawning
threads, e.g. that's how it's running mod_cgi on win32).

A reference to an array of arguments to be passed to the process as
the process' ARGV.

ret: ...

In VOID context returns no filehandles (all std streams to the spawned
process are closed).

In SCALAR context returns the output filehandle of the spawned process
(the in and err std streams to the spawned process are closed).

In LIST context returns the input, outpur and error filehandles of the
spawned process.

since: 2.0.00

It's possible to pass environment variables as well, by calling:

$r->subprocess_env->set($key => $value);

before spawning the subprocess.

There is an issue with reading from the read filehandle ($in_fh)):

A pipe filehandle returned under perlio-disabled Perl needs to call
select() if the other end is not fast enough to send the data, since
the read is non-blocking.

A pipe filehandle returned under perlio-enabled Perl on the other hand
does the select() internally, because it's really a filehandle opened
via :APR layer, which internally uses APR to communicate with the
pipe. The way APR is implemented Perl's select() cannot be used with
it (mainly because select() wants fileno() and APR is a crossplatform
implementation which hides the internal datastructure).

Therefore to write a portable code, you want to use select for
perlio-disabled Perl and do nothing for perlio-enabled Perl, hence you
can use something similar to the read_data() wrapper shown in the
Synopsis section.

spawn_proc_prog() is similar to fork(), but provides you a
better framework to communicate with that process and handles the
cleanups for you. But that means that just like fork() it gives you
a different process, so you don't use the current Perl interpreter in
that new process. If you try to use that method or fork to run a
high-performance parallel processing you should look elsewhere. You
could try Perl threads, but they are very expensive to start if you
have a lot of things loaded into memory (since perl_clone() dups
almost everything in the perl land, but the opcode tree). In the
mod_perl "paradigm" this is much more expensive than fork, since
normally most of the time we have lots of perl things loaded into
memory. Most likely the best solution here is to offload the job to
PPerl or some other daemon, with the only added complexity of
communication.

To spawn a completely independent process, which will be able to run
after Apache has been shutdown and which won't prevent Apache from
restarting (releasing the ports Apache is listening to) call
spawn_proc_prog() in a void context and make the script detach and
close/reopen its communication streams. For example, spawn a process
as:

reopening (or closing) the STD streams and called setsid() makes
sure that the process is now fully detached from Apache and has a life
of its own. chdir() ensures that no partition is tied, in case you
need to remount it.