Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 131
check return value of stream_select including a test case#44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uh oh!
There was an error while loading. Please reload this page.
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.