This is so weak and misguided on multiple levels. A thread is virtual conterpart of the real hardware _thread_ of execution. Without a concept of threads you h

This is so weak and misguided on multiple levels. A thread is virtual conterpart of the real hardware _thread_ of execution. Without a concept of threads you have nothing in the high-level side to map hardware to. Think again before posting this kind of material, it seems to me vaguely embarrassing. Now going upper to the place that you probably find the most familar - a user-space. Truth be told if the app is a unikernel there is almost no overhead in switching threads (just switch the stack and update a bunch of registers). So for unikernel they are perfect abstraction, but you may want to add queues, channel etc on top. Getting to the user/kernel classic OSes - again the problem is lack of trust between user-space and the kernel, the hardware can still switch things quite fast provided we can share most of memory mapping between the two. Nowadays kernel bypass techniques and eBPF running as trusted scripts in the kernel, I do see anything wrong eith threads per see. The architecture pattern of just spawning one new process or thread per connection is bad only if the said processes or threads are expensive to context switch between, and that cost is a rapidly moving target. TL;DR: please stop writing and start reading, there is a lot of homework to do here.