We avoid the problem by using poll(2).
On systems without poll(2) (older bsd-ish systems, and win32), we emulate
poll(2) using select(2) and check for valid descriptors before attempting
to access them via the descriptor sets.
If an out-of-range descriptor is detected, an E_WARNING is raised suggesting
that PHP should be recompiled with a larger FD_SETSIZE (and also with a
suggested value).
Most uses of select(2) in the source are to poll a single descriptor, so
a couple of handy wrapper functions have been added to make this easier.
A configure option --enable-fd-setsize has been added to both the unix and
win32 builds; on unix we default to 16384 and on windows we default to 256.
Windows FD_SETSIZE imposes a limit on the maximum number of descriptors that
can be select()ed at once, whereas the unix FD_SETSIZE limit is based on the
highest numbered descriptor; 256 should be plenty for PHP scripts under windows
(the default OS setting is 64).
The win32 specific parts are untested; will do that now.
Register filters as resources when
instantiated by stream_filter_(ap|pre)pend().
Export php_stream_filter_flush() internal function to wind buffered data
out of a particular filter until consumed by a later filter or sent to
stream->readbuffer or stream->ops->write()
Disables a wrapper (user-defined or built-in) for the life of the request.
Add stream_wrapper_restore()
Restores the wrapper originally defined at the time the request started
to the protocol name mentioned.
Userdefined wrappers were being registered into a global wrapper hash
which can cross threads. Termination of once instance then has the
potential to leave an active stream in another instance with no wrapper
leading to segfault.
using the default socket timeout of 60 seconds before returning the socket
to the calling script. The reason they were using that value is that the
same code is used for feof(), so the fix is allowing the caller to
indicate the timeout value for liveness checks.
A possible remaining issue now is that 0 second timeout[1] for pfsockopen
is possibly too short; it's impossible to specify a sane value for all
possible uses, so maybe we need a stream context or an .ini option to
control this, or maybe use the timeout value that was passed to
pfsockopen().
# [1] by timeout, I mean the time that PHP will wait for data on a
# persistent socket before deciding if a new connection should be made;
# NOT the timeout while waiting for a new connection to be established.
<?php
pfsockopen("foo");
pfsockopen("foo");
?>
Where the transport fails to connect (since args are bogus);
the problem was that the persistent stream entry was not
correctly freed.
