Waitpid does not work as expected in Windows

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
...

Comment on Waitpid does not work as expected in Windows Download Code

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]
Re^2: Waitpid does not work as expected in Windows by athanasia (Pilgrim) on Sep 29, 2008 at 11:33 UTC
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]
Re^3: Waitpid does not work as expected in Windows by ikegami (Patriarch) on Sep 29, 2008 at 11:50 UTC
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]
Re^4: Waitpid does not work as expected in Windows by athanasia (Pilgrim) on Sep 29, 2008 at 12:11 UTC


Perl: the Markov chain saw
	PerlMonks