Re^9: Behavior of threads on XP-- system() works, backtic & popen don't...

And the exact .bat script for looping the test ...

Um. Not quite.

c:\test>555304

c:\test>LOOP:
'LOOP:' is not recognized as an internal or external comm
operable program or batch file.

c:\test>perl 555304.pl
Thread 1
Thread 2
Thread 3



Thread 4

Via system:
hello
world

Via system:
hello
world

Via system:
hello
world

Via system:
hello
world

Via backticks
hello
world

Via backticks
hello
world

Via backticks
hello
world

Via backticks
hello
world

Via pipe
hello
world

Via pipe
hello
world

Via pipe
hello
world

Via pipe
hello
world


c:\test>goto LOOP
The system cannot find the batch label specified - LOOP
[download]

The syntax should be (note the placement of the colon ':' in the first line):

:LOOP
perl 555304.pl
goto LOOP
[download]

However, having corrected that, I did manage to reproduce the hang. I don't know the cause, but at least I have something to work with. You should probably raise a perlbug so that the p5p guys can see what they can see.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^9: Behavior of threads on XP-- system() works, backtic & popen don't... Select or Download Code

Replies are listed 'Best First'.
Re^10: Behavior of threads on XP-- system() works, backtic & popen don't... by Sync (Initiate) on Jun 19, 2006 at 16:55 UTC
And the exact .bat script for looping the test ... Um. Not quite. c:\test>555304 c:\test>LOOP: 'LOOP:' is not recognized as an internal or external comm operable program or batch file. Oops-- my bad. I thought I could type that part in from memory as it was small... Guess not... Sent a perlbug, had also posted it to the ActiveState site, but not a peep. Bug instructions say to send to support@activestate.com as well as perl.org which I did. Glad to see I'm not going crazy-- yet... -- Sync	[reply]
Re^11: Behavior of threads on XP-- system() works, backtic & popen don't... by BrowserUk (Patriarch) on Jun 19, 2006 at 17:13 UTC
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. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l] [select]
Re^12: Behavior of threads on XP-- system() works, backtic & popen don't... by Sync (Initiate) on Jun 20, 2006 at 20:38 UTC
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	[reply]