In my experience simple blocking code is incredibly misunderstood. Most programmers stop their thinking at “blocking is slow and non blocking is fast!”
That only works for workloads that can be independently parallelized. For stuff that cannot be - which is the majority of consumer workload - you're in for a world of pain with locking and whatnot other issues.
- your browser uses a process per tab - your web server responds to multiple requests in parallel - your web app is going to launch other programs - your desktop ui is going to have a compositing server separate from each application - your compiler is going to work on multiple source files
I don't think so. You can't even implement a full-duplex protocol properly with sync IO since reading and writing can't happen at the same time on the same thread. Splitting them to different threads also won't help since accessing shared state requires synchronization with e.g. mutex that kills again simultaneous reading and writing.
With threads the reading and writing can happen simultaneously. The synchronization is only on whatever data you need to share.
Note that if reading and writing are dependent, then single thread actually makes sense because you can’t do one without the other.
Otherwise the pattern of logic you will execute for reading or writing is completely different, which is why threading is the perfect abstraction.
You can write to an eventfd to wake up io_uring listening on an epoll instance.