1

With this code:

poll.poll(&mut poll_events, Some(Duration::from_secs(0)));
for event in poll_events.iter() {
    match event.token() {
        LISTENER_TOKEN => {
            let (mut stream, addr) = unwrap_or_continue!(
                listener.accept(),
                "Failed to accept incoming connection"
            );
            unwrap_or_continue!(
                stream.write("Hello, world!\n".as_bytes()),
                &format!("Failed to write to {}", addr)
            );
        }
        _ => unreachable!()
    }
}

where unwrap_or_continue! just does continue on an error while reporting it, I get this error:

Failed to write to 127.0.0.1:49231: operation would block

Why would it block, the socket just got accepted and it's a first write?

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
Yuri Geinish
  • 16,744
  • 6
  • 38
  • 40
  • 1
    Practically, why does it matter? You need to write your code to handle blocking, otherwise there's no real reason to use MIO. – Shepmaster Apr 17 '18 at 20:11
  • True, I thought `write()` on a nonblocking socket cannot block, but after revisiting `write(2)` docs, it's a valid scenario. – Yuri Geinish Apr 17 '18 at 20:15
  • *a nonblocking socket cannot block* — Isn't that why it returns an error telling you it would have blocked... instead of blocking? – Shepmaster Apr 17 '18 at 20:16
  • @Shepmaster Like I said, revisiting Linux `write(2)` I see that `EWOULDBLOCK` is a valid error. Didn't think that possible before, since it doesn't seem there's anything to block on, as `write(2)` can already return 0 bytes written in case the buffer is full or something. So I was thinking I was doing something wrong with Mio. – Yuri Geinish Apr 17 '18 at 20:26
  • 5
    There's two different points in play here. Your main question is "why does it block in this case", which is a valid enough question. In the comments you seem to be surprised at the *mechanism* of how non-blocking works. Non-blocking sockets work by returning an error whenever the write would have blocked. – Shepmaster Apr 17 '18 at 21:19
  • This type of error happens when there are no more free space for writing into the OS network stack buffer reserved to the connection. No idea why you hit this problem, you should not have such error in your scenario. – attdona Apr 18 '18 at 14:54

0 Answers0