Uh oh!
There was an error while loading. Please reload this page.
check return value of stream_select including a test case - #44
Conversation
cebe
commented
Feb 27, 2016
Additional note about adding |
jmalloc
commented
Mar 1, 2016
Just in case the discussion around From my memory of the PHP source, I guess the take-away from that would be to ensure you're not logging errors that indicate signal interrupts, as I can only assume that would be a blocking I/O operation. |
- error suppression does not hurt much if handled correctly https://github.com/ezzatron/fig-standards/blob/error-handler/proposed/error-handler-meta.md#431-performance-considerations - it make this library work without having to suppress warnings for all the code! - StreamSelect loop is not the loop of choice if you really care about performance anyway. - The "performance overhead" of suppressing the warning will hardly have any effect as stream_select() is supposed to be waiting some amount of time anyway in most cases. In the cases where it returns immediately, the reading and writing of streams will have much bigger impact than the very small amount of time added by @ operator.
cebe
commented
Mar 1, 2016
added a commit for error suppression 5916176 commit message includes detailed resoning about why it should be added. |
cebe
commented
Mar 1, 2016
the test failure on travis is not caused by the changes btw. |
clue
commented
Mar 1, 2016
Changes LGTM |
clue
commented
Mar 1, 2016
FWIW: This is currently only tested for the |
cebe
commented
Mar 1, 2016
It would make sense of course but I'd do another PR after this one is merged. The scope of this PR is fixing an issue that only exists in stream select loop. |
cebe
commented
Mar 3, 2016
@clue@WyriHaximus can we get this one merged please, so I can start checking signal support for other event loops? |
cboden
commented
Mar 3, 2016
On one system I'm getting:
Which can be fixed by checking The other issue I'm seeing is on HHVM 3.6.6:
|
cboden
commented
Mar 3, 2016
I goofed a little bit...phpunit on my HHVM machine was running PHP5 with Debug's scream option turned on (errors not suppressed). Here is the actual error HHVM is giving me:
|
cebe
commented
Mar 3, 2016
done, ef2ced8 Need to install HHVM on my machine to test this. |
cebe
commented
Mar 3, 2016
hm... HHVM fails only on SIGUSR1 but not on the other signals... |
cebe
commented
Mar 3, 2016
Found it, the forked process needs some startup time on HHVM. Added another timer to capture the late signal. |
cboden
commented
Mar 3, 2016
Awesome! Thanks for your diligent work @cebe! |
cebe
commented
Mar 3, 2016
You're welcome, thanks for merging :) |
WyriHaximus
commented
Mar 4, 2016
Thanks for the work @cebe 👍 |
mkrauser
commented
Mar 4, 2016
@cebe Yes, very nice work with the test! |
This PR contains a test case for #20 as requested by @clue and @WyriHaximus. I have also applied the fix by @mkrauser to make the tests pass.
This fixes the issue described in reactphp/reactphp#296.
The test sets up an event loop and then forks a child process which will send a signal to the current process while it is waiting for stream_select(). This triggers stream_select() to return false and throw a warning.
The test currently uses error_reporting to suppress this warning as in the issue discussion the supression of the warning with
@was no wanted. I think there should be a benchmark to check if adding an@to stream select has any negative effect. I doubt it.