Re: Windows fork problem or my ignorance?

Some quick debugging shows that the print loop is reached, but that the hash is empty.

return 0 if $pid < 0; wasn't adjusted for the OS.

Windows doesn't support forking. When you call fork a thread is actually created. For those pseudo-processes, $$ is negative, so wait can return a negative number on success.

Use return 0 if $pid == -1; instead.

Comment on Re: Windows fork problem or my ignorance? Select or Download Code

Replies are listed 'Best First'.
Re^2: Windows fork problem or my ignorance? by romandas (Pilgrim) on Mar 21, 2008 at 12:59 UTC
Thanks! That solved some of the problem, at least the non-printing portion of it. However, when I run it against the range 10.0.1.25..30, I get this: C:\Scripts\Parallel>ping_parallel.pl -4012 is processing 10.0.1.025 -3148 is processing 10.0.1.026 reaping -4012 for 10.0.1.025 reaping -3148 for 10.0.1.026 10.0.1.025 is good 10.0.1.026 is good ## This one finished C:\Scripts\Parallel>ping_parallel.pl -2808 is processing 10.0.1.025 -3424 is processing 10.0.1.026 -2532 is processing 10.0.1.027 -3360 is processing 10.0.1.028 -696 is processing 10.0.1.029 -4036 is processing 10.0.1.030 reaping -2808 for 10.0.1.025 reaping -3424 for 10.0.1.026 reaping -2532 for 10.0.1.027 reaping -3360 for 10.0.1.028 reaping -696 for 10.0.1.029 [download] and sits here. I know that .27 - .30 are not up. Any idea why it sits there?	[reply] [d/l]
Re^3: Windows fork problem or my ignorance? by ikegami (Patriarch) on Mar 21, 2008 at 22:56 UTC
I can reproduce the problem. `wait` never returns. Looks like a bug in Perl. Fortunately, it appears to be fixed in 5.10.0. Read more... (1285 Bytes) Maybe it had to do with `` using `wait` as well. On unix, that wouldn't be a problem since the two calls to `wait` happen in different processes. The pseudo-processes `fork` creates on Windows are just threads, so the two calls to `wait` happen in the same process.	[reply] [d/l] [select]