Skip to content
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

Adds support for UnixStream and UnixListener on Windows #1667

Conversation

KolbyML
Copy link
Contributor

@KolbyML KolbyML commented May 1, 2023

This PR supersedes PR #1610 and solves issue #1609

Background Info

I have spoken with Thomasdezeeuw and his main complaints with the last PR was

It's been a while since I've looked at the pr. But basically I don't want any (substantial) changes to the tests as that would be we would break already existing (Unix only) code that people have written using Mio. Ideally we pave over an platform differences between Unix and Windows

So I was looking into cleaning up the PR and cleaned up some messy edges. I am making this draft pull request just to show in the public where it is at and what I am working on.

Ready for review !!!

The PR is ready review I made it so we didn't have to change the tests. The only test what is different is the try_io doc test which is because the unix one uses pair which isn't supported on Windows. But all the tests in the tests folder matches.

The only addition to the tests would be in tests/UnixStream.rs

assert_would_block(stream.read(&mut buf));

This is because of #1611 which is known about and intentional done this way.

sys/windows/stdnet is a implementation matching the standards libraries implementation of Unix UDS. So if the standard library ever adds support for Unix UDS for windows it should be a drop in replacement.

@KolbyML KolbyML force-pushed the continue-the-work-of-UnixStream-for-windows branch 9 times, most recently from c77065a to 12c4013 Compare May 3, 2023 21:17
@KolbyML KolbyML marked this pull request as ready for review May 3, 2023 23:53
@KolbyML KolbyML requested a review from carllerche as a code owner May 3, 2023 23:53
@leiless
Copy link

leiless commented Sep 15, 2023

Any plan for reviewing/merging this PR?

@Thomasdezeeuw
Copy link
Collaborator

Any plan for reviewing/merging this PR?

Well, this pr has some of the same issues pointed out in previous iterations of this.

After that we need some with some more Windows knowledge to review this properly as I don't use Windows myself.

@KolbyML
Copy link
Contributor Author

KolbyML commented Sep 15, 2023

Well, this pr has some of the same issues pointed out in previous iterations of this.

Would you be able to repost the "issues pointed out in previous iterations of this PR" in this PR. To make tracking the issues what still need to be done easier to track. "previous iterations" had certain changes which you thought took the PR backwards, which is what I tried to resolve in this PR. It is currently unclear exactly what you want. As your statement is quite broad. And the "history" of what you wanted done is confusing because of the reasons I stated before.

Copy link
Collaborator

@Thomasdezeeuw Thomasdezeeuw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, this pr has some of the same issues pointed out in previous iterations of this.

Would you be able to repost the "issues pointed out in previous iterations of this PR" in this PR. To make tracking the issues what still need to be done easier to track. "previous iterations" had certain changes which you thought took the PR backwards, which is what I tried to resolve in this PR. It is currently unclear exactly what you want. As your statement is quite broad. And the "history" of what you wanted done is confusing because of the reasons I stated before.

I pointed out an obvious one, but see #1610 for my other ~40 comments. I'm not going to repeat myself, I simply don't have the time.

Comment on lines +94 to +97
// blocking windows uds which mimick std implementation used for tests
cfg_net! {
pub use crate::sys::windows::stdnet;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're not going to expose this.

Copy link
Contributor Author

@KolbyML KolbyML Sep 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has previously been stated the tests shouldn't change. To make the tests not change we need to have a blocking windows UDS implementation. Having this requirement only leaves us 2 options.

  • 1: Add #[cfg(test)] to the expose so it can only be used in tests
  • 2: Implement UDS support in the rust STD

Would option 1 even be allowed? or an Option?

If it isn't an option then if we want windows UDS in tokio there is a requirement for it being implemented in the STD First. Originally it was thought that we could add Windows UDS since MIO already supports Windows Named Pipes without std support.

So is the precedent that std support is required. That is fine, it is nice to just know that is definitly the step forward. Because the only non-std way to fulfill the no-changing-test-requirement would be option 1.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has previously been stated the tests shouldn't change.

Yes, we need to ensure that the existing behaviour works on Windows as well.

To make the tests not change we need to have a blocking windows UDS implementation. Having this requirement only leaves us 2 options.

  • 1: Add #[cfg(test)] to the expose so it can only be used in tests
  • 2: Implement UDS support in the rust STD

Would option 1 even be allowed? or an Option?

The first option doesn't work as we use Rust's integration tests, which doesn't have access to another crate's #[cfg(test)] exposed items. The second option would be ideal, but that's currently not possible as far as I know.

If it isn't an option then if we want windows UDS in tokio there is a requirement for it being implemented in the STD First. Originally it was thought that we could add Windows UDS since MIO already supports Windows Named Pipes without std support.

So is the precedent that std support is required. That is fine, it is nice to just know that is definitly the step forward. Because the only non-std way to fulfill the no-changing-test-requirement would be option 1.

You're overlooking a third option. Have a blocking implementation inside the test code.

sullivan-sean and others added 2 commits September 20, 2023 11:57
modify src/net for windows compatibility

fix tests

add docs back in

cleanup

remove log statements

clean up selector

clean up stream and listener sys logic

fix re-registration

add test for serial calls to listener.accept

fix serial calls to accept

remove tempfile dependency and fix doc tests

revert change in draining behavior

re-organize stdnet files to mirror std::os::unix::net

use single syscall vectored approach from rust-lang/socket2

lint

improve support across feature matrix

fix doc tests

use bcrypt instead of rand

add -_ to random char set to avoid rejection sampling

optimize rng syscall logic

fix lint and fmt

remove unused functions

fmt

simplify windows mod

clean up tests

fix indentation, imports, address other comments

fmt

remove unrelated code changes

fix lint

remove explicit SetHandleInformation calls

abstract socketaddr behind common API in net

fix lint

add comment clarifying inheritance during calls to accept
@KolbyML KolbyML force-pushed the continue-the-work-of-UnixStream-for-windows branch from 12c4013 to 48db06f Compare September 20, 2023 17:58
@Thomasdezeeuw
Copy link
Collaborator

I'm going to close this because it still needs some work and hasn't seen any activity recently. @KolbyML thanks for the effort!

@simonsan
Copy link

@sullivan-sean @KolbyML Both #1610 and #1667 are closed now. Do you think you can work together on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants