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.