Publishing flamebait [Fwd: Pragmatic Bookshelf releases "From Java To Ruby"]

Barry Roberts blr at
Wed Jun 28 15:33:43 MDT 2006

On Wed, Jun 28, 2006 at 03:14:52PM -0600, Hans Fugal wrote:
> I'm also not very good at enterprise-level performance testing/thinking,
> but I'll venture that insofar as rails is not hindered by the ruby
> threads implementation it's by working around the limitations. What are
> the limitations, exactly?

Well, first, how do you use all the processors on a multiprocessor

J2EE (and ASP.Net, I THINK) are heavily multi-threaded because it's
convenient.  A request can come in to the container, and it can just
look up the associated session information and hand the request off to
any available thread since they share process memory.  Since Java and
CLR use native threads, this automatically uses all the processors in
the machine.

I guess rails could be tightly tied to APR shared memory that helps
apache modules work together even in different processes, but I doubt
that's the case.  I don't know how rails ties to apache or if it does,
but I suspect it would be a real pain on Windows where the default MPM
is threaded.

I'm not saying threads are the only way to make a web-based framework
scalable (I was kinda hoping the rails folks had come up with
something clever).  But they are handy enough that they seem to be
used quite often to make it easy to program in the stateless http


More information about the PLUG mailing list