This loop can block for some minutes, theoretically. Practially
however, this is a 99% non issue for a normal use case. This is
required because read() is synchronous. The PHP streams API wants
to fill its internal buffers, therefore it might try to read some
more data than user has demanded. Also, for a case where we want
to read X bytes, but neither enough data nor EOF arrives, read()
will block until it could fill the buffer. If a counterpart station
runs slowly or delivers not all the data at once, read() would
still be waiting. If we quit too early, we possibly could loose
some data from the pipe. Thus it has to emulate the read()
behaviour, but obviously not completely, just to some grade.
Reading big data amount is for sure an issue on any platforms, it
depends on the pipe buffer size, which is controlled by the system.
On Windows, the buffer size seems to be way too small, which causes
buffer congestion and a dead lock. It is essential to read the pipe
descriptors simultaneously and possibly in the same order as the
opposite writes them.
Thus, this will work with smaller buffer data sizes passed through
pipes. As MSDN states, anonymous pipes don't support asynchronous
operations. Neither anonymous pipes do support select() as they are
not SOCKETs but file descriptors. Consequently - bigger data sizes
will need a better solution based on threads. However it is much
more expencive. Maybe a better solution could be exporting a part
of the internal doing as a userspace function which could perform
some kind of lookahead operation on the pipe descriptor.
This is just the first stone, depending on the user feedback we
might go for further improvements in this area.
Ensure data from OpenSSL internal buffer has been
transfered to PHP stream buffer before a select()
emulation operation is performed
Addresses bug #65137https://bugs.php.net/bug.php?id=65137
Conflicts:
ext/openssl/xp_ssl.c
While this issue is visible in mysqli_poll() functions, the cause
lays deeper in the stream to socket casting API. On Win x64 the
SOCKET datatype is a 64 or 32 bit unsigned, while on Linux/Unix-like
it's 32 bit signed integer. The game of casting 32 bit var to/from
64 bit pointer back and forth is the best way to break it.
Further more, while socket and file descriptors are always integers
on Linux, those are different things using different APIs on Windows.
Even though using integer instead of SOCKET might work on Windows, this
issue might need to be revamped more carefully later. By this time
this patch is tested well with phpt and apps and shows no regressions,
neither in mysqli_poll() nor in any other parts.
if a mode like "rn" was passed to fopen(), then
php_stream_parse_fopen_modes() would assign O_WRONLY to
flags, because O_NONBLOCK tainted flags for the r/w/+ check
_php_stream_copy_to_stream_ex, when mmap is possible, doesn't check
if actually written bytes match read bytes.
Fix this (paranoid check) to be consistent with non mmap mode
Seems hard to add a unit test, as this rely on a full filesystem.
stream_get_line() could contain the delimiter string if that string
had more than one character. The bug manifested itself when a read on
the stream ended with part of the delimiter string and the read after
would start with the rest of the delimiter string; provided that
the data of first read did not complete the max length result of the
call to stream_get_line() with the partial delimiter used in that max
length return. In that case, the delimiter will still appear in
the result, divided in two subsequent return values. That is not a bug.
See <http://www.mail-archive.com/internals@lists.php.net/msg61325.html>
mcq8