Bug #69049 [Fbk->Opn]: Unable to get output of slow process

From: Date: Fri, 13 Feb 2015 13:42:51 +0000
Subject: Bug #69049 [Fbk->Opn]: Unable to get output of slow process
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-190664@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=69049&edit=1 ID: 69049 User updated by: aserbulov at parallels dot com Reported by: aserbulov at parallels dot com Summary: Unable to get output of slow process -Status: Feedback +Status: Open Type: Bug Package: Streams related Operating System: Windows PHP Version: 5.5.21 Block user comment: N Private report: N New Comment: The patch https://bugs.php.net/patch-display.php?bug_id=69049&patch=stream_oef.diff&revision=latest does not fix particular issue - process hangs forever. But the idea is correct - set eof to true only if end of the pipe is reached. Previous Comments: ------------------------------------------------------------------------ [2015-02-13 13:37:30] ab@php.net With your patch, the snippet doesn't terminate. Thanks. ------------------------------------------------------------------------ [2015-02-13 12:37:33] aserbulov at parallels dot com Look at https://bugs.php.net/patch-display.php?bug_id=69049&patch=stream_oef.diff&revision=latest It should fix particular issue... ------------------------------------------------------------------------ [2015-02-13 11:40:16] ab@php.net @aserbulov, there are multiple issues with proc_open - blocking read as file descriptors on windows don't support async, it's not possible to select() - internal streams buffering, say you write 1024 but process.php outs only 4 bytes - pipe buffer size which is way to small on windows, that leads to deadlocks At the end line - it is much more likely to get a proc_open() call hanging before that patch. Not mentioning the cases where process.php (or any counterpart) dies leaking the descriptors - then we've no chance to check it at all. Now we discovered that there is this side effect, however please keep in mind that this topic is way too complicated. For now, maybe it'd make sense to increase the internal retry time to something like 60 seconds. Cheers. ------------------------------------------------------------------------ [2015-02-13 11:27:57] ab@php.net I mean doing it like this process.php <?php sleep(30); // Do some work fwrite(STDERR, "alive"); sleep(30); // Do some work fwrite(STDOUT, 'done'); exit(0); ?> test.php <?php $cmd = "\"" . PHP_BINARY . "\" " . dirname(__FILE__) . "/process.php"; $status; $stdout = ""; $stderr = ""; $pipes = []; $descriptors = [ 0 => ["pipe", "r"], // stdin 1 => ["pipe", "w"], // stdout 2 => ["pipe", "w"], // stderr ]; $process = proc_open($cmd, $descriptors, $pipes); fclose($pipes[0]); while (!feof($pipes[1]) || !feof($pipes[2])) { $stdout .= fread($pipes[1], 1024); $stderr .= fread($pipes[2], 1024); /* throw away */ } fclose($pipes[1]); fclose($pipes[2]); $status = proc_close($process); print_r(["status" => $status, "stdout" => $stdout]); ------------------------------------------------------------------------ [2015-02-13 10:53:00] aserbulov at parallels dot com In any case, you should not break working code during bug https://bugs.php.net/bug.php?id=51800 fixing. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=69049 -- Edit this bug report at https://bugs.php.net/bug.php?id=69049&edit=1

« previous php.bugs (#190664) next »