feat: Move std::net dependencies to sys::net.

[Hywan]

mio provides this great architecture where mio::net defines
user-friendly wrappers to system backends, i.e. sys modules like
sys::unix, sys::windows and sys::shell.

At every step, it's assumed that std::net is available. However,
depending on the backend a user would like to implement, std::net
might not be present. For example, it's assumed that
std::net::{TcpListener, TcpStream} are always available.

That's not always true.

This patch moves the responsability to the backends to declare —or
basically to re-export!— some types from std::net, such as:

• std::net::TcpListener,
• std::net::TcpStream,
• std::net::UdpSocket,
• std::net::SocketAddr,
• std::net::{SocketAddrV4,SocketAddrV6},
• std::net::{Ipv4Addr, Ipv6Addr}.

To achieve that, all of those types above related to std::net are
now in sys::net, those related to TCP are now in sys::tcp, and
finally those related to UDP are now in sys::udp.

It's actually consistent with types that were previously implemented in
sys like sys::tcp::TcpSocket.

With this patch, mio::net has no more dependency to
std::net. Everything comes from sys.

[Hywan]

Note: The src/sys/unix/net.rs file is easier to review with the ?w=1 to ignore indentation changes, https://github.com/tokio-rs/mio/pull/1481/files?w=1.

[Thomasdezeeuw]

mio provides this great architecture where mio::net defines
user-friendly wrappers to system backends, i.e. sys modules like
sys::unix, sys::windows and sys::shell.

At every step, it's assumed that std::net is available.

This is not true, only when the tcp/udp (or net in v0.8) is enabled is std::net required. Otherwise mio::net is not available.

Also I'm not sure what this change actually accomplishes, could you elaborate on what use cases this helps?

[Hywan]

This is not true, only when the tcp/udp (or net in v0.8) is enabled is std::net required. Otherwise mio::net is not available.

Yeah correct, I was too prompt in my explanation, sorry for that.

Also I'm not sure what this change actually accomplishes, could you elaborate on what use cases this helps?

Everytime mio::net uses TcpListener, TcpSocket, TcpStream etc., their definitions come from mio::sys. Then it's up to the “backends” (sys module) to expose them. For the actual code, it's just a matter of re-exporting them.

But I'm working on an experimental WASI support, and thus I need to implement custom TcpListener, TcpStream and so on, types. We can't use the ones from std::os::wasi because it's not here yet (it's a bunch of unsupported!()). With this patch, it's so much simple :-). The “backends” are responsible to expose all the types manipulated by the mio::net “facades”/wrappers.

Thoughts?

[Thomasdezeeuw]

This is not true, only when the tcp/udp (or net in v0.8) is enabled is std::net required. Otherwise mio::net is not available.

Yeah correct, I was too prompt in my explanation, sorry for that.

Also I'm not sure what this change actually accomplishes, could you elaborate on what use cases this helps?

Everytime mio::net uses TcpListener, TcpSocket, TcpStream etc., their definitions come from mio::sys. Then it's up to the “backends” (sys module) to expose them. For the actual code, it's just a matter of re-exporting them.

But isn't that the same as having std::net be the "backend" in the current code.

But I'm working on an experimental WASI support, and thus I need to implement custom TcpListener, TcpStream and so on, types. We can't use the ones from std::os::wasi because it's not here yet (it's a bunch of unsupported!()). With this patch, it's so much simple :-). The “backends” are responsible to expose all the types manipulated by the mio::net “facades”/wrappers.

I know wasi doesn't support sockets currently (or at least last I checked), but can't you turn of the net feature(s)? I still don't know what this pr actually changes.

Thoughts?

Also I have an wip (and now outdated) port of Mio to wasm in pr #1395.

[Hywan]

But isn't that the same as having std::net be the "backend" in the current code.

If std::net is missing the type we want to implement, then we are blocked. In the case of wasm32-wasi, let's take the example of TcpListener: this type exists in std::net but it's full of unsupported!() definitions. Then we are blocked, we can't implement WASI support except by waiting on libstd to implement it.

But by “moving the std::net types inside” the backend, we can create a new “backend”, like you did in #1395, and create our own implementation of TcpListener. It's really useful for wasm32-wasi but it might be also useful in other contexts where Rust doesn't provide a complete implementation for std::net.

Basically, this patch replaces the imports from std::net to sys::net (and sometimes sys::tcp or sys::udp or sys::uds depending of the requested type).

:-)

[Thomasdezeeuw]

But isn't that the same as having std::net be the "backend" in the current code.

If std::net is missing the type we want to implement, then we are blocked. In the case of wasm32-wasi, let's take the example of TcpListener: this type exists in std::net but it's full of unsupported!() definitions. Then we are blocked, we can't implement WASI support except by waiting on libstd to implement it.

But by “moving the std::net types inside” the backend, we can create a new “backend”, like you did in #1395, and create our own implementation of TcpListener. It's really useful for wasm32-wasi but it might be also useful in other contexts where Rust doesn't provide a complete implementation for std::net.

But if std lib doesn't provide TcpListener for a target than neither is Mio. I'm not going to maintain an entire socket implementation in Mio. Socket2 (which I also maintain) is a better place for that, the best being std lib of course.

Basically, this patch replaces the imports from std::net to sys::net (and sometimes sys::tcp or sys::udp or sys::uds depending of the requested type).

I can read that from the code, but what I want to know is what benefit does this bring to Mio over the current situation?

As far as I can tell wasm doesn't have a way to create a socket currently, so even with this patch accept the net features still won't work for wasm do they?

[Thomasdezeeuw]

Since I'm still not convinced of the usefulness of this change I'm going to close it. @Hywan if you still want to continue with this feel free to reopen.

[Hywan]

:-)