Bug #69900 [Fbk->Asn]: Commandline input/output weird behaviour

From: Date: Wed, 01 Jul 2015 16:08:36 +0000
Subject: Bug #69900 [Fbk->Asn]: Commandline input/output weird behaviour
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-194042@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=69900&edit=1 ID: 69900 User updated by: nerdbeere2k at gmail dot com Reported by: nerdbeere2k at gmail dot com Summary: Commandline input/output weird behaviour -Status: Feedback +Status: Assigned Type: Bug Package: *General Issues Operating System: Windows PHP Version: 5.5.26 Assigned To: ab Block user comment: N Private report: N New Comment: Hello ab, thanks again for investing your time into this! I tested the php executable from here http://windows.php.net/downloads/snaps/ostc/69900/php-7.0.0-dev-Win32-VC14-x64.zip with the code from your mail, so that: $process = proc_open(PHP_BINARY.' -f test.php', $descriptorspec, $pipes, null, null, array("blocking_pipes" => true)); and added an fflush($pipes[0]) after the fwrite. However, i somehow can't replicate your test-times... This is what it looks like with "blocking_pipes" => true: >.\php-7.0.0\php.exe -f passproc.php hello0 fgets() took 17.000913619995ms hello1 fgets() took 99.004983901978ms hello2 fgets() took 100.00610351562ms hello3 fgets() took 100.00586509705ms hello4 fgets() took 100.00610351562ms hello5 fgets() took 100.00491142273ms hello6 fgets() took 100.00610351562ms hello7 fgets() took 100.00586509705ms hello8 fgets() took 100.00610351562ms hello9 fgets() took 100.00491142273ms and this is what it looks like with "blocking_pipes" => false (or without setting $other_options at all): >.\php-7.0.0\php.exe -f passproc.php hello0 fgets() took 100.00610351562ms hello1 fgets() took 100.00586509705ms hello2 fgets() took 100.00514984131ms hello3 fgets() took 100.00586509705ms hello4 fgets() took 100.00610351562ms hello5 fgets() took 100.00586509705ms hello6 fgets() took 100.00514984131ms hello7 fgets() took 100.00586509705ms hello8 fgets() took 100.00610351562ms hello9 fgets() took 100.00491142273ms Using this version with java produces the same behaviour. So, somehow like before, after the first two reads. Hope this helps. Previous Comments: ------------------------------------------------------------------------ [2015-07-01 15:11:04] ab@php.net @nerdbeere2k could you please check the build http://windows.php.net/downloads/snaps/ostc/69900/ which is linked in this mail http://news.php.net/php.internals/86976 ? Please be aware that you'll need add a stream context and/or additional proc_open config. The patch is unlikely to appear in PHP5, but in PHP7. Be aware that this way can lead back to dead locks, though might be useful when used carefully. The actual issue is - if the caller doesn't send EOF, the input seems to be buffered. So while PHP peeks the pipe, nothing is there. Seems that even if caller flush()es, it doesn't affect the pipe. So when it happens, PHP enters a timeout, and when peeking next time, the data seems to be available in the pipe. That's why fe the snippet like ... echo hello | php ... works as expected - because the echo command does properly close(). If we don't use peek()ing technique, blocking reads and dead locks can happen, which was reported many times. In addition to this patch for PHP7 I'm going to investigate on ways to improve the situation in PHP5. Not sure we should even thing about unbuffered IO on pipes, but at least about decreasing the timeouts or maybe enforcing buffer flush before peek()ing. Thanks. ------------------------------------------------------------------------ [2015-06-29 20:57:34] cmb@php.net Related To: Bug #69963 ------------------------------------------------------------------------ [2015-06-28 14:50:35] nerdbeere2k at gmail dot com Hello ab, i didnt have time to respond until now, but i hope this still helps. i set up a vm and tested this on debian and can confirm that this is a windows only issue! ------------------------------------------------------------------------ [2015-06-26 20:19:29] ab@php.net @nerdbeere2k, thanks for the additional input. Ok, i've compiled your java snippet and tested on windows and linux. It clearly shows, that it's a Windows only issue. Were nice if you could confirm that. Also it shows that proc_open isn't involved. Still i suspect pipe handling. But this already gives the direction to debug. Thanks. ------------------------------------------------------------------------ [2015-06-25 18:50:55] nerdbeere2k at gmail dot com Hello ab, first: thanks again for replying! i must admit i didnt test my last code snippet with Linux, but initially i got a report for my java application which stated that it'd run very slow since upgrading php to 5.6. The environment from that report is Linux, and after i investigated the problem i supposed that this was the source of the problem without specifically testing it on Linux... So i might've been wrong, and if you say so, i probably was and i'm sorry for that! I will take Linux out of the OS list. Concerning proc_open(): i don't think the problem is related to proc_open(), because the java and the php snippet basically do the same thing and the timings and output of both are pretty much equal... I'm also not sure what we're investigating on :) i had hoped maybe someone had an idea what to do! What would you advise? ------------------------------------------------------------------------ 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=69900 -- Edit this bug report at https://bugs.php.net/bug.php?id=69900&edit=1

« previous php.bugs (#194042) next »