-
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
TcpStream & TcpListener rely on internals #880
Comments
Sorry for the delay. It looks like you found a work around? I'm not entirely sure I follow the original question. In general, the windows impl strategy is most likely going to significantly change in the future. I expect we will use a strategy similar to http://github.com/piscisaureus/wepoll. |
@carllerche Yes I found a workaround, although it's not something we want to stick with long-term. @arsing describes the problem more succinctly in this comment on deprecrated/mio-uds#7. |
The problem we're trying to solve is that we want mio-uds and downstream crates to support Unix Domain Sockets on Windows. Currently we have a hacky way of doing this that involves duplicating a lot of code from libstd, mio and mio-uds into https://github.com/Azure/mio-uds-windows and using As Damon mentioned in the OP of this issue and I wrote in deprecrated/mio-uds#7 (comment), the I wanted to see if it was possible to abstract out the internals of That change is here. It creates a bunch of new traits that can be implemented by any With this, mio-uds can have struct UnixListenerImp;
impl mio::windows::Listener for UnixListenerImp { ... }
struct UnixListener {
inner: SocketListener<UnixListenerImp>,
}
struct UnixStreamImp;
impl mio::windows::Stream for UnixStreamImp { ... }
struct UnixStream {
inner: SocketStream<UnixStreamImp>,
} What do you think of this approach? Would it be something that can be merged into mio 0.6 ? Is there a better way of doing this? |
Right. As I said in our email conversation, if the wepoll implementation results in an |
@carllerche I ran into the need for wepoll/epoll/kqueue myself, as part of my work on Inko. Since MIO has various issues with Windows, and the API isn't stable (and seems to be scheduled for lots of changes based on the various issues), I ended up writing my own wrappers around these libraries. For epoll and kqueue I used the
The wepoll-sys crate bundles the wepoll code and compiles it upon installation, as I don't have the time and resources to port the code to Rust. The wepoll-binding crate provides a safe interface around wepoll-sys. The safe bindings are fairly lightweight, and the API is based on (and should feel similar to) MIO. Using these crates might be useful for MIO, and I'm happy to review any patches MIO might need to make things work. I haven't gotten to extensively testing both though (only minor testing to get CI going), so there might be some bugs. p.s. should MIO be interested in using these crates, it might be worth renaming |
If I'm reading this correctly basically this issue asking for a |
That's right; see #880 (comment) It would presumably be Then the UDS side can forward to |
I'm not a Windows guy, but would also need a wrapper around a |
The |
Now that #1064 is merged I'm working on this, I intend to provide a |
@Thomasdezeeuw what would this look like? I'm not sure how something like that would work for windows, except maybe: #1047 |
@carllerche my current idea is to add a wrapper type that adds |
oh, you mean an internal refactor? |
Yes, but also make the wrapper type public. |
I'm just not sure how we can make the wrapper type public. It is pretty specific. I would love to hear your planned strategy. |
@carllerche I already implementation something here: https://github.com/tokio-rs/mio/pull/1183/files#diff-2ace2cbf884d3de3ae825a07c3e5bffdR101. Usage in But like I said I don't really like the API as its rather fragile to use, but its modelled after |
Right, I see how you could model an abstraction that is used across TCP & UDP internally. I just don't see how it can become a public API. |
This isn't going into alpha1. |
We still don't have a good solution for this, but I want to release v0.7 so punting this to v1. |
I could not find a way to get mio 0.7 running with Windows' uds. So, until tokio-rs/mio#880 (deprecrated/mio-uds#7) is implemented in Mio we use a simple blocking event loop for Windows. That's fine, it's just for the RPC. We could potentially see some load on a server, but it'd be on UNIX so Everything Is Fine ™️. Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
I could not find a way to get mio 0.7 running with Windows' uds. So, until tokio-rs/mio#880 (deprecrated/mio-uds#7) is implemented in Mio we use a simple blocking event loop for Windows. That's fine, it's just for the RPC. We could potentially see some load on a server, but it'd be on UNIX so Everything Is Fine ™️. Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
I could not find a way to get mio 0.7 running with Windows' uds. So, until tokio-rs/mio#880 (deprecrated/mio-uds#7) is implemented in Mio we use a simple blocking event loop for Windows. That's fine, it's just for the RPC. We could potentially see some load on a server, but it'd be on UNIX so Everything Is Fine ™️. Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
I could not find a way to get mio 0.7 running with Windows' uds. So, until tokio-rs/mio#880 (deprecrated/mio-uds#7) is implemented in Mio we use a simple blocking event loop for Windows. That's fine, it's just for the RPC. We could potentially see some load on a server, but it'd be on UNIX so Everything Is Fine ™️. Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
I could not find a way to get mio 0.7 running with Windows' uds. So, until tokio-rs/mio#880 (deprecrated/mio-uds#7) is implemented in Mio we use a simple blocking event loop for Windows. That's fine, it's just for the RPC. We could potentially see some load on a server, but it'd be on UNIX so Everything Is Fine ™️. Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
I could not find a way to get mio 0.7 running with Windows' uds. So, until tokio-rs/mio#880 (deprecrated/mio-uds#7) is implemented in Mio we use a simple blocking event loop for Windows. That's fine, it's just for the RPC. We could potentially see some load on a server, but it'd be on UNIX so Everything Is Fine ™️. Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
I could not find a way to get mio 0.7 running with Windows' uds. So, until tokio-rs/mio#880 (deprecrated/mio-uds#7) is implemented in Mio we use a simple blocking event loop for Windows. That's fine, it's just for the RPC. We could potentially see some load on a server, but it'd be on UNIX so Everything Is Fine ™️. Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
This is not going to block a v1.0 release. |
We're keeping the current AFD based implementation, so there isn't anything to do here. |
I'm working on UDS support for Windows. I hope to start with my own mio-uds-windows crate and maybe get it merged into mio-uds at some point. I'm new to all this so I'm probably missing something obvious, but I've had a really hard time finding a good starting point for my Windows UnixStream and UnixListener.
The obvious choice was to start with mio's TcpStream and TcpListener. But I can't build them outside of the mio codebase. They make use of SelectorId, which isn't public. I can make a copy of the SelectorId code, but it accesses the private
selector
field onPoll
. Also, they wrap the publicmio::windows::Binding
withReadyBinding
. When I copy that type, it won't build because it accesses the privateselector
field to get/put buffers down inBufferPool
.I could start from mio-named-pipe, but it only implements the stream not the listener, it doesn't implement
read_bufs
/write_bufs
(even if it did, it wouldn't be able to use the internalBufferPool
), and it preallocates memory and does an extra copy for reads (8K).Anyway, I'm wondering if it would be possible to extricate TcpStream and TcpListener in such a way that they make a good example for other streams and listeners, but without breaking things?
The text was updated successfully, but these errors were encountered: