So for me the really big question in all of this is "Are threads really too heavyweight?". This obviously needs the constraint "on a sane, modern OS". For me t

So for me the really big question in all of this is "Are threads really too heavyweight?". This obviously needs the constraint "on a sane, modern OS". For me the most sane C (non-datagram) networking model at least on Linux is threads, each calling accept concurrently (afaik few people know this is supported) and then handling the accepted connection until that is closed. For systems where you only want to handle a fixed number of connections like databases you keep your number of threads fixed for others you start a new thread once every other thread handles a connection already. It gets rid of Thread Pools (since you only do pthread_create() when your number of concurrent connections increases), Async- and callback-hell and makes all your handling code linear. Every other day I keep seeing "Blabla uses async epoll so handles 10k connections" but a) what serious work can you do with 10k connections i.e. 125 kB/s per connection @ 10 Gbit/s. b) at what cost to readability/maintainability of code and c) are you sure you haven't just moved your bottleneck to something else? Also I've never seen any benchmark showing how this actually beats threads on a modern Linux box. As for shitty OSs I say fuck them