When you're receiving from a network socket over the Internet, blocking a (real) thread until all the data arrives is pretty inefficient.
Yes, but it's still how the overwhelming majority of network code functions. It's not really till the rise of libev/libuv and friends that people start moving to non-blocking as a default (I spent pretty much an entire year of my life convincing an AWS team to reclaim 4 GB of thread stacks by moving to non-blocking I/O).
> or return an "incomplete message" error meaning that the caller is the one to continue reading.
That's pretty un-user-friendly.
It's also how all non-blocking I/O worked prior to languages adding native async functionality.
Yes, but it's still how the overwhelming majority of network code functions. It's not really till the rise of libev/libuv and friends that people start moving to non-blocking as a default
It's also how all non-blocking I/O worked prior to languages adding native async functionality.
Meh. AOLServer showed that you could do better back when I was in high school. I've given up worrying about ecosystems that haven't got it yet.
Comments
Yes, but it's still how the overwhelming majority of network code functions. It's not really till the rise of libev/libuv and friends that people start moving to non-blocking as a default (I spent pretty much an entire year of my life convincing an AWS team to reclaim 4 GB of thread stacks by moving to non-blocking I/O).
It's also how all non-blocking I/O worked prior to languages adding native async functionality.
Meh. AOLServer showed that you could do better back when I was in high school. I've given up worrying about ecosystems that haven't got it yet.