OP explained things improperly, then. It's an important detail, because Rails currently defaults to single-threaded. This makes an operation such as fetching and returning a twitter feed in a single request (assuming it takes hundreds of milliseconds to get a response from twitter's servers) expensive.
Only rookies do that inside the web server process.
The job of fetching a Twitter feed can be offloaded to a background jobs queue. With a little help from Nginx, you can free the Ruby process to take care of other requests until the response of that Twitter feed is ready.
Or you could simply deploy your Rails app on top of a Java server, by means of JRuby and forward that request to a servlet that uses the continuations support in EE 6, offloading the request to an Akka actor and freeing the pipeline until it is ready. Works great and you can even write everything in Ruby ;-)
Ruby has no support for concurrency, no matter how many threads your interpreter is using. 1.8 had no OS threads at all, and 1.9 has a global interpreter lock. This is not solvable in the application layer (for example, by a framework like Rails): this is a problem inherent to the runtime.
JRuby is fully parallel with no global lock and many people choose it for deployment. Rubinius 2.0, which is in development, will also lack the GIL.
You're also very confused about how threading on Ruby MRI 1.9 works. First of all, pure Ruby code in 1.9 can and does execute on multiple OS threads, in parallel.
Also, the problem that the Ruby VM still has is that while executing native code, it does not allow a context switch unless that code explicitly informs the VM that it can do a context switch. This is in effect how the global interpreter lock works. The gotcha here is that native extensions that are well behaved, can inform the VM that a context switch is possible. For instance, the older "mysql" gem was NOT well behaved, blocking context switches between threads, but the newer mysql2 gem does behave well and works correctly in multi-threading.
Right now, if you start a new Rails 3 app, it will work in a multi-threading environment correctly and modern Rails servers are taking advantage of that, unless you install some older gems that haven't been fixed. The biggest problem is that you can't know what libraries are well behaved, but if that's too much of a burden, JRuby is a fully supported platform for Rails and doesn't share the same issue.
Pure Ruby code in MRI 1.9 can run on multiple OS threads, but it can't run on multiple OS threads in parallel. Here's some reading you can do if you're unsure:
Yes: Ruby can allow native code to execute in parallel with Ruby code (although it doesn't always do so, as you note). But if you're under the impression that multiple Ruby threads can execute in parallel, you're wrong. That may or may not be a problem, depending on what you need Ruby to do.
JRuby can be a good option for parallelism, but it's also slower than Ruby MRI 1.9 and has an ecosystem that most Ruby developers will be unfamiliar with. Regardless, my point was that Rails doesn't magically "work with multithreading," at least for standard Ruby deploys.
