response: We *are* blocking!

[mrkline]

We're not using some event-driven async I/O, that's the whole point of this crate. The sockets are not set up as non-blocking and we should only expect EWOULDBLOCK from recv() on timeouts.

[mrkline]

Correct me if I'm wrong - POSIX OSes (Mac and Linux) don't return EWOULDBLOCK from syscalls like recv() unless:

1. they're configured as non-blocking with fcntl(..., O_NONBLOCK), and the same seems to be true for Windows: https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-recv
2. They timed out (bit of a misnomer, but so it goes.)

I think we could make similar changes to code in native_tls/, let me know!

[neonmoe]

Good point! I kinda thought that reading from the socket would be similar to waiting for a mutex or similar, where you might get "spurious wakeups" though I've never seen them. But if wouldblock only really happens on timeout with blocking sockets, it seems like a good idea to just not handle wouldblocks anywhere, except for detecting timeouts.

For timeouts though, rather than doing it in response.rs, I'd rather check for wouldblock in HttpStream's read implementation, and return Err(timeout_err()) instead of wouldblock. Response should just pass the errors to the user.

[mrkline]

You're right, that's much cleaner! Pushed an updated patch.

[neonmoe]

Thanks for another contribution, much appreciated!