Stdin and Stderr too definitively have this problem. And I fully expect it's possible to get the same problem with other file descriptors, e.g. by explicitly opening a terminal device. And of course you can `dup2()` stdout and get an fd that `!= 1` and yet I believe it will share the `O_NONBLOCK` flag.

Also, if we don't have this problem with other fds, then they'll never trigger this code.

The errno of read/write being overwritten is unfortunate. However, according to the man pages, the only errors that `fcntl()` can return for `F_GETFL` and `F_SETFL` are `EAGAIN`/`EWOULDBLOCK` and `EBADF` (a linux manpage indicates `EPERM` is possible, but only when clearing `O_APPEND` and we're not doing that). And of course `EBADF` is a legitimate error from `read`/`write` as well, so I'm not worried about it.

I don't believe this will cause an infinite loop, unless there's some way the system can return `EAGAIN`/`EWOULDBLOCK` when the `O_NONBLOCK` flag is not set. I checked and the only other way I found for that to happen is with `O_NDELAY`, which a) isn't POSIX, and b) seems to be equal to `O_NONBLOCK` on everything I looked at except for Linux on sparc, which we don't support. I could certainly add in code to ensure that the flags do have `O_NONBLOCK` set, but I don't expect that code to ever catch anything.

Continually retrying is necessary. Fds are a shared resource (certainly among threads, and as this bug indicates, certain file descriptors share their flags among processes). So libnative could remove `O_NONBLOCK` only to have something else immediately set it again before libnative has a chance to re-enter `read()`/`write()`. Therefore, doing this in an infinite loop is necessary. If it makes you feel any better, it makes progress on every pass through the loop, and it will eventually end (and of course it *should* only ever need a single retry in pretty much every single case. I will be pretty surprised if anyone actually manages to need multiple passes through the loop).