为什么Apache没有可行的mod_ruby呢？

Question

像Ruby和Rails一样流行，似乎这个问题已经解决了。 JRuby和mod_rails都很好，并且很棒，但为什么没有Apache Mod直接用于Ruby呢？

Answer 1

基本问题是这样的：很长一段时间，MRI是唯一可行的Ruby实现。 MRI有一些问题，很难将其嵌入到另一个应用程序中（这基本上是mod_ruby所做的：它在Apache中嵌入了MRI），尤其是多线程（Apache）。它不是特别的线程安全的，它具有相当的全局状态。

这一全球性的状态意味着，例如，如果一个Rails应用程序修改某些类，那么，同样的Apache服务器上运行的所有其他 Rails应用程序，将也看到这个修改的类。

另一个问题是MRI源代码不容易被破解。 MRI现在已经超过15年了，现在已经开始显现。

由于这些问题，mod_ruby从来没有真的正常工作，并在某些时候维护者只是放弃了。

另一方面，基于C的PHP解释器是从第一天开始设计的，它在Apache内运行为mod_php。事实上，对于前几个版本，甚至没有一个命令行版本的解释器，mod_php是运行PHP的仅有的方式。

Phusion Passenger (aka mod_rack aka mod_rails)通过基本放弃和回避问题解决了这个问题：他们只是在每个应用程序的独立过程中运行MRI的单独副本。它非常棒，不仅适用于Ruby。它支持WSGI（Python Web框架的标准接口），Rack（Ruby Web框架的标准接口）和直接支持Ruby on Rails。

我的希望在于mod_rubinius，遗憾的是它还不存在。 Rubinius的设计从一开始就是线程安全的，可嵌入的，没有全局状态，不使用C栈等等。它旨在能够在一个Rubinius流程内运行多个Rubinius虚拟机。这使得mod_rubinius比mod_ruby更容易实现和维护。不幸的是，Rubinius目前还没有发布，并且在Rubinius发布之前，mod_rubinius上的真正工作甚至还没有开始。好消息是mod_rubinius已经比mod_ruby拥有更多的人力资源，因为它支付了Rails托管公司的开发者付出的代价，绝望地想要自己使用它。

Answer 2

有一个：mod_ruby，但它在2年左右没有维持。

Answer 3

Phusion Passenger是一个强大的Apache模块，可以使用最低配置运行Rack应用程序。这已经成为吸引共享主机，并打开任何程序到机架上的应用是非常的简单：

机架应用是红宝石对象 （不是类），响应call。 ，也恰恰是一个参数，在 环境和返回 正好三个值数组：状态中， 头和身体。

Answer 4

这可能值得双重澄清mislav的观点，mod_rails实际上并不限于Rails代码。新名称mod_rack更好。平凡的小应用程序可以是机架式 - 他们的例子是：

class HelloWorld 
    def call(env) 
    [200, {"Content-Type" => "text/plain"}, ["Hello world!"]] 
    end 
end 

Answer 5

有mod_rails，它可以运行Rack应用程序，你还能需要什么？