ruby-on-rails-3 – 为什么rails不完全支持将事件代码写出来

在Node.js出来之后,这是普及的事件编程的一件事.
但是,Ruby确实有EventMachine,它支持编写事件代码.

支持事件的要求是：
运行反应堆的事件服务器(薄,彩虹)
2. Fibres(Ruby 1.9.3)为了使写入事件的代码更容易,否则我们可以使用线程.
所有的gems事件(例如MysqL2).

Nodejs显示出事件编程的明显好处.那么为什么rails社区不采用eventmachine？我认为rails不能完全移植到eventmachine的原因之一是因为依赖于可能不会被发生的底层宝石.但是有人知道有没有计划在这个方向上迈出一步呢？

Rails可以做Nodejs做的工作,但是Nodejs是通过倡导所有图书馆制作者的事件编程开始的,所以按照大多数依赖关系,你添加到节点中的package.json,你知道它将被事件发生,并且会与nodejs一起使用盒子.

解决方法

最大的原因是Rails生态系统不是用于事件IO的,而是在您的应用程序中引入了一个非事件的IO,从而消除了这些好处.在Ruby(和Rails)中编写事件代码是非常有可能的,但并不一定很简单,因为宝石做或不执行事件IO并不总是清楚,开发人员需要花很多时间追逐应用程序可能阻止的位置.相比之下,Node创建的隐含的理想是IO永远不会是同步的,并且它的整个生态系统都从这个理想流出,这意味着开发人员不必担心他们的IO操作是否会同步或不;默认的假设是它们是异步的.

此外,事件的Web应用程序只有在IO绑定时才非常有用.如果您的应用程序是cpu限制的,或正在进行大量的同步cpu工作,则事件模型可能不是正确的方法. Ruby可能需要大量的cpu,主要是由于语言的元编程结构和垃圾收集器(应在Ruby 2.1中大大改进),这可能使其不太适合于事件事件编程.

Rails有许多并发模型可供选择,分叉,抢先线程和事件处理 – 由开发人员选择最适合其应用领域的开发人员.分叉是默认的,因为它很容易,不需要任何特殊的注意事项(只要您在POSIX系统上部署！),并且Ruby在创建Rails时没有系统线程.现在,使用Ruby 1.9(系统线程,GIL)和JRuby(无GIL！),线程代码非常容易部署. Ruby 2.0带来了一个COW友好的垃圾收集器,这意味着分叉比以前更有效率.

在一天结束时,事件代码不是默认代码,因为它需要开发人员的更多工作,对于许多人来说,默认分支模型是足够好的.在不存在的情况下,开发人员可以选择线程或事件代码,最适合其基础设施和应用程序域.

原文地址：https://www.jb51.cc/ruby/271763.html