undefined | Better HN

0 pointsswiftcoder4y ago0 comments

> 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.

0 comments

1 comments · 1 top-level

lmm4y ago

> 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.

j / k navigate · click thread line to collapse