You have a script, say 'util', and you kick it off by typing a command something like:

    $ util -x this that
[download]

Which runs perl, telling it to run the util script with the three arguments you specified. So, this code gets run:

    if(  @ARGV  &&  $ARGV[0] eq "-child"  ) {
        shift( @ARGV );
        # child code here
        exit( 0 );
    }

    # Am parent
    # ...
    system( 1, $^X, $0, "-child", @ARGV ); # run child
    # ...
[download]

And @ARGV is set to ( '-x', 'this', 'that' ). So the first line checks @ARGV in a scalar context which gives us its number of elements, 3, which isn't 0 so it is true and we try the expression after the &&.

$ARGV[0] is '-x', which isn't the same string as '-child' so the 'if' fails and the code in its block gets skipped.

So system( 1, $^X, $0, "-child", @ARGV ); gets run. The '1' tells system to not wait for the command that it starts. This only works in OS/2 and Win32 (and probably still isn't documented).

So the next argument says what program to run. $^X is the name of the file containing the Perl interpreter, something like '/usr/bin/perl' or just 'perl'. So the perl interpreter gets run in a new child process and we don't wait for it to finish.

The first argument passed to perl says what script to run so we put $0 so the child process runs our same script (again).

Next we pass in "-child" and our @ARGV and these end up in @ARGV in the child process.

So when the above code gets run in the child process it is true that $ARGV[0] eq "-child" so the 'if' block gets run.

        shift( @ARGV );
        # child code here
        exit( 0 );
[download]

The shift removes the '-child' so that @ARGV is now the same as in the parent.

The comment should be replaced with whatever code you want run in the child.

And the exit prevents the rest of the code (meant for the parent in this example) being run in the child.

So the effect is very much like fork.

- tye        

Thanks for the explanation! It looks like all I really need is that "1," in my system call, and I can do away with forking altogether. I'm just trying to launch "fire and forget" exe files here.

system(1, 'this.exe');

I guess my only other question, then, is "why doesn't ActiveState implement something like this?"...

--


Believe nothing, no matter where you read it, or who said it - even if I have said it - unless it agrees with your own reason and your own common sense.
(Buddha)

This may very well have been true back in 2001, I do remember having problems if I loaded DBI before fork()ing, but I AM running several multithreaded services (daemons for the Unixers) for two or three years already. Works fine. I do not keep creating and destroying threads though, in one service I only have two threads ("watcher" and "worker"), the number of threads in the other depends on the INI file, but again I create them upfront.