I've been scoping out ruby for an upcoming server project.

For my purpose, performance will be a factor because the server will
be slending data in real-time much like a multipayer game server such
as Quake (as opposed to waiting for user input).  Quake is an extreme
example, though -- it wouldn't be nearly that demanding.

I am very impressed with WEBrick, and this would be my primary choice
were it not for performance concerns.

How does WEBrick scale?  Looking through the code, it appears that new
requests are handled by a ruby Thread -- as opposed to a native thread
or a fork.  What happens with 40 threads, all transferring data and
doing stuff, all being handled by a single ruby process setjmp-ing and
longjmp-ing around?  I'm guessing performance would be poor.

Next option is mod_ruby.  Now I don't even understand how mod_ruby
works with Apache 2.0 since the ruby interpreter isn't thread-safe.
So that's all a mystery to me.  Apache 1.3 + mod_perl is probably
well-tested and perhaps the most appropriate choice.

Are the above assumptions correct, and are there other options?  One
more option which comes to mind is to simply write a forking ruby
server from scratch.  This would mean more development time, but how
much more I'm not sure.