Bug #69900 [Fbk->Asn]: Commandline input/output weird behaviour
| From: | nerdbeere2k at gmail dot com | 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