为什么Apache还没有一个可行的mod_ruby?

这是 Phusion Passenger ,一个可以运行的强大Apache模块 Rack 具有最低配置的应用程序。它对共享主机越来越有吸引力,将任何程序转换为Rack应用程序都非常简单:

Rack应用程序是一个Ruby 对象 (不是类)响应 call . 这完全需要 一个论点 ,the 环境,并返回一个数组 确切地 三个值 :状态 头部和身体。

基本问题是:在很长一段时间里,MRI是唯一可行的Ruby实现。MRI有很多问题,很难将其嵌入到另一个应用程序中(这基本上就是 mod_ruby 确实如此:它将MRI嵌入Apache中),尤其是多线程(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 Frameworks的标准接口)和对Ruby on Rails的直接支持。

我的希望还在 mod_rubinius 不幸的是,这还不存在。 Rubinius 从一开始就被设计为线程安全、可嵌入、无全局状态、不使用C堆栈等。它被设计为能够在一个Rubinius进程中运行多个RubiniusVM。这使得mod_rubinius比mod_ruby更容易实现和维护。当然,不幸的是,Rubinius还没有发布,在Rubinius发布之前,mod_Rubinius的真正工作甚至无法开始。好消息是,mod_rubinius已经拥有比mod_ruby更多的人力,因为它通过Rails托管公司向开发人员支付了费用 拼命地 他们想自己使用它。

也许值得再次澄清mislav的观点,即mod_rails实际上并不局限于rails代码。新名字mod_rack要好得多。微不足道的小应用程序也可以被破解,例如:

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

有一个: mod_ruby ,但它已经两年左右没有维护了。

这是 mod_rails 它可以运行 Rack 应用程序,你还需要什么?