Re: win32 open3 strangeness

Replies are listed 'Best First'.
Re^2: win32 open3 strangeness (classic race, no fork) by tye (Sage) on Dec 15, 2004 at 15:15 UTC
IPC::Open3 doesn't use fork on Win32. This is the classic race condition inherent in using open3. The subprocess is blocking waiting for the output to be read and so isn't reading while the parent is blocked writing to the subprocess waiting for the subprocess to read. Or the subprocess is blocking reading while the parent is blocking reading output that the subprocess has buffered and so isn't available for reading yet. And there is no good way to get around this because you can't tell if you are going to end up in the first deadlock case or the second. Using select could help except select doesn't work on non-sockets in Win32. You could use a Win32::SelectablePipe instead of pipe except that I don't think the (broken) snippet from tye's scratchpad has been turned into a CPAN module yet by my minions. ;) - tye	[reply]
Re^3: win32 open3 strangeness (classic race, no fork) by BUU (Prior) on Dec 15, 2004 at 23:22 UTC
Er, what you say makes a certain amount of sense, but why is it blocking at the actual open3() call? Why wouldn't it block when I try to read or write?	[reply]
Re^4: win32 open3 strangeness (classic race, no fork) by tye (Sage) on Dec 15, 2004 at 23:54 UTC
I don't believe it is. If you think it is, then present some evidence. Come to think of it, I'd be surprised if this were the problem at 488 characters. 512 I could believe. But perhaps it is printing out some other stuff? With the few precise details provided, it is a big guessing game. - tye	[reply]
Re^5: win32 open3 strangeness (classic race, no fork) by BUU (Prior) on Dec 16, 2004 at 00:50 UTC
Re^6: win32 open3 strangeness (no fork!) by tye (Sage) on Dec 16, 2004 at 00:59 UTC
Some notes below your chosen depth have not been shown here


laziness, impatience, and hubris
	PerlMonks