Nonblocking I/O

[alexcrichton]

A frequently requested feature of I/O I've been seeing is some form of nonblocking I/O. This is a vast and broad topic, but I would like to make this concrete proposal:

fn set_nonblocking(&mut self, nonblocking: bool) -> IoResult<()>;

The IoErrorKind enum would also be extended with a value of WouldBlock. This method would be added to only the network streams initially and possibly others as later seen fit.

For libnative, this would do the ioctl thing or whatever the equivalent is to set the file descriptor into nonblocking mode (can this be done on windows?). For librustuv, this could be a little more difficult. To the best of my knowledge libuv doesn't support a nonblocking read. One possible solution would be to schedule a read and then use an idle callback to cancel the read on the next turn of the event loop. This would technically block the task, but it would be for "a short period of time"

Those who desire a form of nonblocking I/O, would this satisfy your needs?

[sfackler]

This would work for me. This would only affect the result of reads, not writes, correct? The librustuv issue is a bit unfortunate but as long as the event loop is quick, not the end of the world.

[alexcrichton]

Hm, nonblocking writes is indeed a large problem. I don't know of a way to do a nonblocking write with libuv.

[bnoordhuis]

It's not currently possible but it could be made to work if uv_cancel() was taught to cancel uv_write_t requests. Fairly trivial on Unices, maybe less so on Windows.

[bnoordhuis]

Forgot to mention, libuv grew a uv_try_write() function in v0.11.16 but it's currently only implemented on Unices. I don't know how difficult it would be to make it work on Windows.

[alexcrichton]

Closing in favor of #13336