RFC: Stop using std::net types (TcpStream / UdpSocket) about mio HOT 15 CLOSED

You forgot UdpSocket in your strategy.

Do you think that the Error::from_os_error issue is something that should be discussed upstream? Surely mio will not be the only library with this concern.

from mio.

@Hoverbear I have mentioned it and I believe they will stabilize it, but not until 1.0 Final would be my guess. If std::io::Error was the only issue, it wouldn't be worth changing anything. However, this change would be required to get Mio running on windows. So, I was hoping to postpone the change, but the std::io::Error issue is bringing it up now.

from mio.

I would rather stay on nightlies and use the std types with unstable APIs, if that's possible. I don't think it's actually crucial we get this building on stable rust at 1.0, since it is in a highly experimental area of rust development.

from mio.

Requiring nightlies after 1.0 would greatly limit mio's audience.

from mio.

I like the idea of one library that support the same platforms rust itself supports over using the std types.

from mio.

I'm in favor of this; at the moment lack of Windows support is the only thing keeping me from using mio for a handful of side projects. It would be great to have platform parity with rustc.

from mio.

We are using mio in a couple of projects. All of them will stay on nightlies after 1.0, at least until compiler plugins are stable. Windows support is not important for us, but I guess it would be nice to have for some people. (without additional overhead for *nix part).

But there are some things that I would prefer be different. After last mio reform my colleagues asked me a lot of questions about code like this

match sock.read_slice(...) {
                Ok(Some(n)) => { .. },
                Ok(None) => { .. },
                Err(e) => { .. },
            }

It's very confusing and non intuitive. I believe Option is not ideal way of communicating WouldBlock.

Smth like this would be great.

match sock.read_slice(...) {
                Ok(n) => { .. },
                Err(Mio::WouldBlock) => { .. },
                Err(Mio::Eof) => { .. },
                Err(e) => { .. },
            }

Explicit eof instead of n == 0 would be great too.

With Result<_, mio::Error> it will be possible again.

from mio.

@rozaliev I thought a bunch about how to communicate WouldBlock, and IMO the issue is that, when working with non-blocking sockets, a WouldBlock case is not actually an error. The reason this matters is, if using try!(sock.read_slice(...)), a WouldBlock would end up returning early from the function.

If all mio sockets are assumed to be non-blocking, NonBlock could be repurposed as it was in 0.2:

match sock.read_slice(...) {
    Ok(NonBlocK::Ready(n)) => { .. },
    Ok(NonBlock::WouldBlock) => { .. },
    Err(e) => { .. },
}

from mio.

I personally would prefer if we reused Option, as it reduces imports and is more compatible with other code that already operates on Option values.

from mio.

I think I also personally prefer the Option signature, but it is open for discussion :)

Anyway, got Mio running on Rust 1.0 beta w/o these changes, so there isn't a huge rush now. I think version 0.4.0 will target windows support, which will require some of what I proposed initially. I'll try to post a more in depth windows support plan when I have a moment.

from mio.

Out of interest, what would TcpStream and friends look like if they were moved into mio? Would it still be possible to read/write to them in a synchronous fashion if needed?

from mio.

The versions in mio would probably be hard coded to be non-blocking. However, there could be conversions between mio::TcpStream and std::net::TcpStream and the mio EventLoop could support registering std::net::TcpStream (and others), but only on posix systems.

from mio.

Would this affect Mio's ability to interoperate with openssl crate's SslStream<S> for example? Actually, is that even possible today for Mio to event on an SslStream<S> type?

from mio.

@jnicholls It shouldn't make it harder. I believe it would be possible for Mio to work w/ a non-block SSL stream type. We could discuss it further on the #mio IRC channel.

from mio.

I'm going to close this in favor of #155. Trying to keep things clean...

from mio.