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

Hi monks! I am using ActivePerl-5.8.8 in a Windows XP OS.
I want to do a simple fork and exit parent when child returns. The problem is that waitpid() never seems to return something other than 0 and the program hangs with the error message "Perl Command Line Interpreter has encountered an error and needs to close".
I have seen several posts questioning Perl's ability to fork correctly in Windows systems. I would appreciate any help. I am posting my code: 
use Win32::OLE('in');
use POSIX":sys_wait_h";
my $pid = fork();
my $check;
die "can't fork:$?" unless(defined $pid);
if ($pid != 0) {
    print "I am the parent\n";
    my $flag = 0;
    while ($flag == 0) {
        $check = waitpid($pid,&WNOHANG);
        print "Waitpid returned $check\n";
        if ($check > 0) {
            print "Parent caught death of child $pid\n";
            $flag = 1;
        }
        else {
            sleep 1;    
            print "Not yet caught\n";
        }
    }
    print "Parent is exiting\n";
}    
else {
    print "I am the child\n";
    sleep 3;
    print "Child is exiting\n";
    exit (0);
}

[download]
The output I am getting is :
I am the parent
Waitpid returned 0
I am the child
Not yet caught
Waitpid returned 0
Not yet caught
Waitpid returned 0
Not yet caught
Waitpid returned 0
Child is exiting
Not yet caught
Waitpid returned 0
Not yet caught
Waitpid returned 0
...

Replies are listed 'Best First'.
Re: Waitpid does not work as expected in Windows
by ikegami (Patriarch) on Sep 29, 2008 at 10:47 UTC

    Remember that fork creates threads that look like processes (rather than actual processes) on Windows.

    use Win32::OLE('in');

    It works fine when I remove this. Do you have any reason to believe it's thread-safe?

    if ($check > 0)

    The pseudo-processes created by fork on Windows have negative PIDs. That should be if ($check != -1).

[reply]
[d/l]
[select]
      Thanks for your reply!
      I did not know that pids in Windows were negative.

      Also, your suggestion about removing
      use Win32::OLE('in');
      solved the problem. Unfortunately, I need this module because the code snippet I posted is part of a larger project that needs Win32::OLE->GetObject function. Do you know what causes this incompatibility? Is there a way in Perl to use a module for a part of the program and disable it for the rest rather than defining it in a global scope?

      Thanks in advance
[reply]

        I did not know that pids in Windows were negative.

        They're not. That's why negative numbers were used to id the pseudo-processes created by fork.

        Do you know what causes this incompatibility?

        The usual possibilities:

        • A race condition. Not very likely here considering the simplicity of the code and the repeatability of the problem.
        • Something that should only be called once is being called once for each thread.
        • Something is called from one thread but expects to be called from another.

        On the Perl side, every variable gets copied when you create a new thread. That makes Perl code more-or-less thread-safe by default. But that's not the case on the C component of XS modules. C variables are shared among threads "by default".

        Workarounds:

        • If you only need Win32::OLE in the parent, you could try loading it after all threads have been created. This will probably entail using require instead of use.
        • If you only need Win32::OLE in the child, you could try loading it from the thread. This will probably entail using require instead of use.
        • If you need Win32::OLE in both the parent and the child, it probably won't work based on the evidence we've seen. Using separate processes would do the trick.
[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom