> Switching async tasks involves loading the new task from memory onto the stack. That's it.
One of the points on the list was that if the context switch is due to I/O readiness, then there's more work for the async task to do [0]:
> Think about it this way—if you have a user-space thread which wakes up due to I/O readiness, then this means that the relevant kernel thread woke up from epoll_wait() or something similar. With blocking I/O, you call read(), and the kernel wakes up your thread when the read() completes. With non-blocking I/O, you call read(), get EAGAIN, call epoll_wait(), the kernel wakes up your thread when data is ready, and then you call read() a second time.
> In both scenarios, you’re calling a blocking system call and waking up the thread later.