Tim Bray makes some assumptions about threading and scalability here:

In that recent Ruby piece, I remarked that Ruby threading struck me as kind of feeble, and that threading is getting real important. Well, I know one way to solve that problem. So I tracked down JRuby geek Tom Enebo and got some news and he pointed to me to some code that I think is pretty cool.

On that threading thing, Tom tells me that “We currently implement Ruby threads using Java native threads. It is our plan to continue doing so.” So, JRuby is ready for the threading era.

That may not be the best way to handle it. We actually have some good experience in this area, due to the port of Opentalk (our communications framework) to ObjectStudio for the last release. ObjectStudio maps its threads down to platform (in this case, Windows) threads. That makes them non-deterministic and much harder to control. It also means that any error made by a developer in an individual thread has the ability to tie things up very nicely - at the platform level.

In VisualWorks, threads are green. This makes them really, really inexpensive. For instance, in BottomFeeder, I spawn a thread per feed (I'm subscribing to 309 as I write this). I don't need to worry about thread pools, or overwhelming the platform. If I tried such a feat with native threads, I'd have to worry about those things.

Sure, you'll say, but what if I have a multi-CPU (or multi-Core) box that I want to take advantage of? Simple - run more than one image (process) and have them communicate as needed. That's actually the classic Unix approach to scaling, and it works quite well. The programming model is vastly simpler - I don't have as many complex synchronization issues to deal with. External APIs (such as database calls, etc) can already be threaded at the platform level, so you don't have a blocking issue.