Edit report at https://bugs.php.net/bug.php?id=75538&edit=1
ID: 75538
Comment by: samel dot chemla at orange dot com
Reported by: samuel dot chemla at orange dot com
Summary: stream_set_blocking() always returning false for
files on windows
Status: Closed
Type: Bug
Package: Streams related
Operating System: Windows
PHP Version: 7.1.11
Assigned To: ab
Block user comment: N
Private report: N
New Comment:
Hi!
I know this is an old topic, but I just saw the doc http://php.net/manual/en/function.stream-set-blocking.php
was updated with that note: "On Windows, this has no affect on local files. Non-blocking IO for
local files is not supported on Windows."
My understanding is that stream_set_blocking does *not* work for regular files, whatever the OS is.
Then if this is correct, then:
* the windows note should be removed from the documentation,
* this statement should be fixed: "This function works for any stream that supports
non-blocking mode (currently, regular files and socket streams)."
* stream_set_blocking() should return false, whatever the OS is. IE linux implementation should be
fixed because actually it returns true.
Can you clarify?
Regards.
Previous Comments:
------------------------------------------------------------------------
[2018-01-26 16:47:03] ab@php.net
Closing as per request. Thanks for documenting, Matt.
------------------------------------------------------------------------
[2018-01-23 02:53:11] mattficken@php.net
stream_set_blocking() for local files can't be supported on Windows.
I have updated the documentation notes to state that.
This bug can probably be closed now.
------------------------------------------------------------------------
[2017-11-22 10:04:39] samuel dot chemla at orange dot com
Hi,
Thanks for your answer.
I didn't realize the implication of this, and I understand it's not a priority.
I'm not C developper, but I would be happy to help on PHP side (testing?)...
Maybe we should at least update the doc to mention that non blocking file acces cannot (yet :-)) be
guaranteed.
------------------------------------------------------------------------
[2017-11-21 15:01:33] ab@php.net
Thanks for the further explanation. With reactphp - yep, the topic was discussed at least with Bob
several times. However it regards more to standard file descriptors and pipes. Regular files are a
different matter.
What i was basically asking for was a bare implementation in PHP as a show case to evaluate
crossplatform. A flag being true/false is a bit insufficient :) Regular files are always available.
The I/O performance depends on quite some factors like caching, compression, encryption, etc. Libs
like libeven or libuv use also threading besidses the libc APIs. Just by changing a flag passed to
the C API likely won't guarantee anything. Even if done, the system can still decide to go
synchronously. An option here could be to cache those files in RAM, if possible.
So in first place - it is barely a bug in PHP, disregard the OS. The socket APIs support
non-blocking crossplatform. It might be for sure a significant chunk of work to spread this onto
regular files, standard descriptors and pipes. For what it matters, I'd be not really convinced
ATM it is worth and specially is possible without significant userspace API rework :( Perhaps libuv
and other bindings are a worthy option in this regard. At the current stage, even if the
non-blocking flag can be changed on some platforms, it doesn't guarantee non-blocking with the
regard to possible obstacles.
Thanks.
------------------------------------------------------------------------
[2017-11-21 10:16:54] samuel dot chemla at orange dot com
I made a mistake in my previous comment, you must read
array(9) {
...
'blocked' =>
bool(false)
...
}
(I copied/pasted the result without "n" mode)
------------------------------------------------------------------------
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=75538
--
Edit this bug report at https://bugs.php.net/bug.php?id=75538&edit=1