As has been alluded to by others above, the AS implementation of the fork function in the Win32 environment is, an emulation, actually using spawning a native Win32 thread (termed a pseudo-process, see the perlfork html/pod that comes with AS distributions). Whilst in many situations this works well enough, it does mean that the 'parent' thread in the process will hang around dormant until the forked pseudo-process (child thread) goes away.

The simplist way of starting a detached process to run asynchronously from your CGI (or any other perl script) is to use the system function in conjunction with the Win32 CMD native command START. Eg. Issuing the following command from perl script

system( 'start d:\perl\bin\perl.exe -V -e"<>"' );
[download]

Note:The command I ave used is only by way of demo. Depending upon your set up, you may not need to specify the full path to the executable, or even name the executable in the command at all.

will cause the system function to return immediately and a new process will be started to run the command supplied after the start command.

There a two caveats with this. One is that if the command cannot be found, a pop-up will be displayed and the original script will block until this popup is dismissed, at which point system returns a value of 256 and $! will contain "No such file or directory". I haven't discovered any way of defeating this annoying behaviour.

The second is that assuming the process to be started is a console application (like perl.exe or simiar), then a new console window will be created for the process. This can be overridden using the /B switch, which means that the new process will share the console of the originating process. Provided that the new process doesn't produce any output or this has been redirected somewhere, then it shouldn't interfere with the CGI program in any way.

This is similar to the behaviour of commands detached with & in the *inix environment and is easily dealt with.

Your final, and most flexible option in the Win32 environment is to use Win32::Process. The greater flexibility comes at the cost of some extra complexity and a lack of good documentation within the Win32::Process package itself which forces you to seek Win32 platform documentation on the CreateProcess API. In this, Google is your friend:)

There are various other options to the start command that may or may not be useful to you. type help start at a command line near you for further details:)