add include for missing usleep proto

C89 compat

Merge branch 'PHP-5.6'

* PHP-5.6:
Update NEWS
fix typo
Added test and review suggestion
Fix bug #68335: rmdir doesnt work with file:// stream wrapper

Merge branch 'PHP-5.5' into PHP-5.6

* PHP-5.5:
Added test and review suggestion
Fix bug #68335: rmdir doesnt work with file:// stream wrapper

Added test and review suggestion

Fix bug #68335: rmdir doesnt work with file:// stream wrapper

proper dllexport

fix datatype mismatches

add include for usleep() proto

Merge branch 'PHP-5.6'

* PHP-5.6:
increase the polling period to not to break existing behaviours

Merge branch 'PHP-5.5' into PHP-5.6

* PHP-5.5:
increase the polling period to not to break existing behaviours

increase the polling period to not to break existing behaviours

Merge branch 'PHP-5.6'

* PHP-5.6:
updated NEWS
Fixed bug #51800 proc_open on Windows hangs forever

Conflicts:
main/streams/plain_wrapper.c

Merge branch 'PHP-5.5' into PHP-5.6

* PHP-5.5:
Fixed bug #51800 proc_open on Windows hangs forever

Fixed bug #51800 proc_open on Windows hangs forever

This loop can block for some minutes, theoretically. Practially
however, this is a 99% non issue for a normal use case. This is
re

Fixed bug #51800 proc_open on Windows hangs forever

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.

show more ...

s/PHP 5/PHP 7/

fix type

master renames phase 4

master renames phase 3

first shot on merging the core fro the int64 branch

restore API compatibility

finish

refactor _php_stream_fopen_{temporary_,tmp}file()

Fixes to various stream cast on win64

This fixes further issues on win64 with casts from the streams.
Sockets/descriptors handling was unitized. This has an impact only on
win64, php

Fixes to various stream cast on win64

This fixes further issues on win64 with casts from the streams.
Sockets/descriptors handling was unitized. This has an impact only on
win64, php_socket_t otherwise can be feed back to int datatype.

show more ...

Bump year