> It's hard to imagine a web application where one HTTP request comes in and a dozen threads (or processes, whatever) are spawned.
Really? I think that's a failure of the author's imagination. Nearly every web application that I've worked on since 2003 has had a significant amount of concurrency involved in handling each request.
The project I'm working on right now (Rails) could certainly use the hell out of it. Hell, people were thrilled by how much faster things were after I pushed everything that didn't need to happen at request-time into the background queue.
Just having futures to keep database access would help, although I'm not sure how that would be possible with Rails' lazy querying.
All that said, the core Ruby guys are probably better off spending their time on performance enhancements than removing enough of the GIL to allow that kind of multithreaded shenanigans.
At minimum, doing your data fetching in parallel / asynchronously is a huge boost. Likewise flushing to the client in concurrent / out-of-order chunks, possibly in parallel with other work.
Really? I think that's a failure of the author's imagination. Nearly every web application that I've worked on since 2003 has had a significant amount of concurrency involved in handling each request.