HTTP is a protocol without specification when it comes to async./sync. Most HTTP is sync. because non-blocking IO and concurrent memory access are hard to make

HTTP is a protocol without specification when it comes to async./sync. Most HTTP is sync. because non-blocking IO and concurrent memory access are hard to make without side effects that our society does no not like; like dropping slow clients or using locks and chasing threading bugs f.ex. My web/app-server is one of the few that does it all without bloat: parallel + async. with concurrent data structures and non-blocking IO; it means all cores can cooperate on the same problem at the same time without waiting for anything. IO-wait is where most current sync. server solutions loose ~20% of the CPU when a system is under high utilization. Comparable to what you loose on the kernel which is what many people are trying to remove with user-space networking. It's also because of IO-wait that services break, a completely Joint Parallel system is very hard to break, it gets increased latency instead. All Joint Parallel systems have a queue built in because there is no point to spawn more threads than there are cores. I'm trying to find a name for it because things usually needs a name to spread, and Joint Parallel is the best I got so far.