arkamedis21 has asked for the wisdom of the Perl Monks concerning the following question:

Hi,
I am having trouble with this script in windows, where I am forking off close to 10 processes, and then trying to capture their output. The code works fine on UNIX, but hangs on windows. Please Help. Thanks. 


for (my $i=0; $i < 10; $i++) {
    $pid = fork;
    if ($pid == 0) {

        my $dir_cmd = "dir";
        my @output = `$dir_cmd`;

        exit 1;
    } elsif ( defined ($pid) ) {
            # parent
            $process_count++;
            push(@pids,$pid);
            print "job $pid forked \n";

    } else {
        # fork error

        print "fork failed with code $pid n";
        exit 1;
    }
}

[download]

Replies are listed 'Best First'.
forking in Windows is not what you may think
by Rex(Wrecks) (Curate) on Apr 25, 2002 at 15:56 UTC
    The forking in windows does not actually fork processes, it is an implementation of threading. And as most know, threading is experimental in Perl and definatly not stable.

    I have tried a couple "forking" excercises in Windows and have never gotten consistant results. There are other workarounds, but I don't have them off the top of my head. Other monks may have options for you.

    This has been one of my main "Perl with Win32" beefs as well.

    Sorry I couldn't be more helpful than explaining why it has odd behavior.

    Update: For external applications look into Win32::Process and Win32::IProcess (the only place I can now find the latter). Both are handy for dealing with processes and spawning new processes in Win32.

    "Nothing is sure but death and taxes" I say combine the two and its death to all taxes!
[reply]
Re: forking in winblows ?
by dhable (Monk) on Apr 25, 2002 at 16:05 UTC
    I'm not understanding the point of forking ten processes to all do a dir command on the same directory in parallel. It seems like a better move would be to send all of the threads after different resources. This leads into your problem. Windows is trying to protect it's filesystem by locking access to the directory. If you run your script enough, sometimes you get a directory listing and other times you don't. Each process is trying to run dir but entering into a deadlock situation with each other.

    The only reason I can see this running on Unix is the multiuser nature of Unix. Are you running this on a FAT or FAT32 partition? These were only designed for a single user system. Thus they don't have options for reading data without locking it. I don't have access to a Windows NT box but I suspect that if you try it on a NTFS system it will work.
[reply]
      Actually your comments on FAT and FAT32 are not quite true, especially when it comes to the dir command. They do have options for reading data without locking, it's WRITING that requires a lock.

      And I seriously doubt that the dir command is the issue here, since system() is being used dir would behave as normal and just wait to access any locked data until its (actually the redirectors) internal timeout gets kicked, and then barf a semephore timeout error.

      I ran into the exact same issue trying to fork in Windows, and if you want, change the 'dir' to an 'echo' command, chances are you will hit the same thing.

      "Nothing is sure but death and taxes" I say combine the two and its death to all taxes!
[reply]
[d/l]
      The dir command is just a simplified example on what is causing the problem in my larger script, and I don't think this has to do anything with the file system because if i was to replace:

      my @output = `$dir_cmd`;

      with a system call

      system("$dir_cmd");

      it works with even a 100 process's in parallel, the reason I son't want to use a system call is because I want to get the output and store it within a file

      I even looked trying something like this:

      system ("$dir_cmd >> out.txt");

      but the output comes all mangled up, with so many process's trying to write to the same file at once, so I just store the output in a variable, and then copy it to the file within the smae child process, and it works for me in UNIX.

[reply]
        So why not put the commands into a batch file and pipe the output of the commands to a file? 
        test.bat
--------
dir c:\some\path\ >>c:\path\to\test.txt

        [download]
        then use the system call and read the output in perl: 
        system("c:\path\to\test.bat"); 
open(OUTPUT, "<c:/path/to/test.txt") || die "couln't open ...yadda..."
+;
@output=<OUTPUT>;
close(OUTPUT);

        [download]

        Just my $0.02.
        Matthew Musgrove
        Who says that programmers can't work in the Marketing Department?
        Or is that who says that Marketing people can't program?
[reply]
[d/l]
[select]
        I even looked trying something like this:
        system ("$dir_cmd >> out.txt");
        but the output comes all mangled up, with so many process's trying to write to the same file

        Did you try something like this: 

        system( "$dir_cmd > out$i.txt" );

        [download]
        so that each thread would write to a different output file?

        Or, since you just want to read output from commands that are running in subshells, have you looked at creating an array of file handles that open "$dir_cmd |"? I haven't tried it, but I expect it would be possible (maybe even really simple) to loop over that array of handles doing non-blocking reads until their all done. (But I'm not running my windows partition just now, so I'd have to try it some other time...)

[reply]
[d/l]
Re: forking in winblows ?
by rbc (Curate) on Apr 25, 2002 at 16:27 UTC
    I wonder if installing cygwin would help.
[reply]
      I already have cygwin, but since this script will launch on many other machines later on which might or might not have cygwin, I have not tried using their fork();
[reply]

Back to Seekers of Perl Wisdom