Skip to content

Comment on Implementing a toy version of TLS 1.3parent

Comments

When you're receiving from a network socket over the Internet, blocking a (real) thread until all the data arrives is pretty inefficient.

I'm perplexed at this statement, and the rest of your post in general. How is that "inefficient"? What else can the thread do if it needs to process data that hasn't arrived yet?

On the other hand, I've rewritten a lot of code where someone thought adding lots of complexity to a fundamentally simple task would somehow be better, and gotten some real performance gains from it. Almost always, the straightforward and simple approach wins.

I'm perplexed at this statement, and the rest of your post in general. How is that "inefficient"? What else can the thread do if it needs to process data that hasn't arrived yet?

Some other task, such as processing data from a different socket that has arrived now. A library monopolising a thread for this one operation is like those DOS-era applications that expected to monopolise the whole CPU for their application - sure, it's "simpler", but it's vastly less efficient.

(And doing your network I/O async should not be complex or confusing in any serious modern language)

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.