-
Notifications
You must be signed in to change notification settings - Fork 732
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
Port gaea tests #1070
Port gaea tests #1070
Conversation
Check that the event::Source implementation is correctly called.
There is some overlap in what is tested now however.
Note that there is some overlap in the tests for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 cheers.
When no data is available to read/peek the socket should return a WouldBlock error.
|
||
// Expect the stream to be non-blocking. | ||
let mut buf = [0; 20]; | ||
assert_would_block(stream.read(&mut buf)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@carllerche here's a test that ensure the stream to be non-blocking, per what you mentioned on Gitter.
Doesn't work, see issue tokio-rs#1070.
Before it could be that only one of the connections would be ready to be accepted, result in would-block errors.
It seems Linux and macOS handles shutting down the reading side differently. Linux still allows the remaining buffer to be read, while macOS doesn't. |
Shutting down the reading side is pretty much unspecified and has no meaning at the TCP level. I wouldn’t bother testing it. |
What happens is different on each OS, for example on Linux we can still read but on macOS and FreeBSD we can't.
In a attempt to fix the TcpStream shutdown_read test.
They both fails, be it's unknown to me why. It needs further investigation for which I've opened tokio-rs#1074.
Ideally we can get this merged sooner than later as it has the non-blocking fixes. |
@carllerche sorry for the delay, I haven't had much time recently to work on this. As for the failures; there are a number of network issues which should resolves itself. The only actual failures are on Windows the I could ignore the tests for now on Windows so we can merge this and open an issue for it to fix it later. |
On Windows the error is ConnectionAborted rather then BrokenPipe.
I think something strange is going in the |
Issue tokio-rs#1078 is opened to investigate why they fail on Windows only.
Issue tokio-rs#1079 is opened to investigate why it fails on Windows only.
Issues tokio-rs#1080 is opened to investigate why.
@carllerche CI finally green, I've opened a number of issue to investigate why the tests fail on Windows, but I currently don't have the time to investigate. In any case the is ready for a review. |
Looks great! we can iterate more on master in follow up PRs. |
Doesn't work, see issue #1070.
Still have to port the tests for
TcpStream
andTcpListener
.