3 ms·
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 wr
by bvrmn 2y ago
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 2y agoThat 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 2y agoI don't argue that async/await could match manually written io loop for specific task. You started with blocking read/write and threads.