[bvrmn]

Model 2 is wrong, most of async/await implements this:

Nonblock read(), if EAGAIN: append fd into event waiting queue, wait event and read() again

Nonblock write(), if EAGAIN: append fd into event waiting queue, wait event and write() again

For loaded systems EAGAIN case is quite rare and syscall count is same.

[fefe23]

That is an assumption and generalization you can't make. In fact it is usually wrong. I invite you to do actual measurements before claiming things as fact in the future.

I, for example, implement an async web server and your case basically never happens. You get a connection, you call read, there is not going to be data yet. In fact calling read immediately is basically wasted effort, so I'm not doing it. I save one syscall over your proposal right away. Optimizations like TCP fast open might change this over time, but definitely won't when you do SSL. You need to wait for a request and then for replies. SSL involves several additional back and fros over plain TCP.

Writing is worse unless you tell the OS to provide ungodly buffer space per connection, which you shouldn't, because then your server won't scale.

[bvrmn]

I don't argue that async/await could match manually written io loop for specific task. You started with blocking read/write and threads.