Hacker News new | ask | show | jobs
by rogers12 1313 days ago
That's a blast from the past. Incredible that 10 years ago people thought using a thread per request is a good idea because anything else is too hard.
3 comments

I'd argue that thread-per-request is even a better idea now, given the massive number of cores and memory in modern servers.
Hybrid?

Request passed to a thread pool. Each thread is juggling coroutines representing in flight requests

Is that worth the complexity? I like the way Go does it. The runtime is managing the actual threading and async IO as it schedules go routines, but to the programmer it all looks like normal synchronous code.
thread per request doesn't imply kernel threads. And I'm pretty sure even a kernel thread per request in a faster language is going to be better than asincio in python.
BEAM has user level processes and can run millions of them in a not too huge VM.