I've tried to trace this through, but I haven't found a work-around. It appears to be hanging at this Win32_msgwait() (win32.c:3976):

    else  {
        DWORD status;
        win32_msgwait(aTHX_ 1, &ProcessInformation.hProcess, INFINITE,
+ NULL);
        /* FIXME: if msgwait returned due to message perhaps forward t
+he
           "signal" to the process
             */
        GetExitCodeProcess(ProcessInformation.hProcess, &status);
        ret = (int)status;
        CloseHandle(ProcessInformation.hProcess);
    }
[download]

The first parameter in that call (1), is meant to indicate the number of handles that should be waited for, but this code was probably written before the advent of threading, hence the constant. I think what is happening is that in a multi-threaded app that spawns concurrent child processes on different threads, the number of process handles eligable can be more than one, and under some circumstances, the one that should be waited upon is not the first one. Hence it deadlocks. I think.

The whole treatment of how the unix concept of wait & waitpid are emulated under Win32 relies on some fairly dubious coding from what I can see and I am unable to see a simple work-around to allow it to work properly in a multi-threaded environment. I've given a little thought on how it might be restructures, but making it work mutli-threaded without screwing up or imposing undue overhead for single threaded Perl woudl require a deeper understanding of the Unix concepts than I have.

Certainly the "fixme" seems a bit dubious. I believe even in Unix you aren't guaranteed to get the processes in wait() in any particular order, so code has to make allowances for wait getting the wrong thing, though I don't know what happens in Unix/Linux threads as that's rather new and I've not had any experience with it...

I figured it was something like this though... ActiveState send me a response that it was in the "core" so it's up to the Perl5 porters. I also noticed a bug ID-- 33096 "win32_msgwait runs forever" that appears to be related to a message coming in while it's waiting for a process handle...

-- Sync