You can mix and match. For work, I run a conferencing server ... packet processing runs in one thread per core, out of band signalling runs in async on a separate pool of threads. It used to all be async, but using threads for packet processing shaved a little cpu, doing my own timers shaved a little cpu, cpu pinning the threads and the sockets shaved a little cpu, and at the end of the day we shaved a couple instances... too bad instance cost is immaterial compared to bandwidth. Also, it probably drives my coworkers crazy ... but there's really only one spot where it causes issues, so eh, it's fine.
For other things, async task (or green thread, whatevs) per connection is a very nice model that you can't do with thread per connection because I don't think OSes are happy to gave hundreds of thousands of threads.
> For other things, async task (or green thread, whatevs) per connection is a very nice model that you can't do with thread per connection
I don’t think I ever seem this patterns, What I’ve seen is either a thread pool for tasks (what essentially async is), or dedicated threads for each parts of the processing (a thread for the UI, and a thread for some background services like playing music).
For other things, async task (or green thread, whatevs) per connection is a very nice model that you can't do with thread per connection because I don't think OSes are happy to gave hundreds of thousands of threads.