我想对此提出一些意见,因为它有助于指导我在研究中应该关注的内容(如果我应该考虑线程)。
是否存在Rails应用程序的示例,其中线程是绝对必要的,并且多进程模型无法提供适当的解决方案。一个例外是具有内存限制的应用程序,需要使用线程而不是生成多个进程。但假设内存不是问题,那么线程是更好的选择还有什么其他情况呢?
答案 0 :(得分:1)
线程更容易编写和调试。我将从简单的非线程代码开始,对其进行调试,然后在最后用Thread.new
和join
包装一个块,然后我就完成了。
而且,是的,研究它们。您将学习有用的技巧并获得在“编程工具箱”中有用的知识。
至于线程可以做什么,那个进程不能?线程可以非常轻松地共享数据并在同一队列或队列中工作。使用单独的进程执行此操作需要数据库或IPC或使用消息传递队列,所有这些都会增加许多复杂性(尽管它们也可以增加容量。)
答案 1 :(得分:0)
通常,线程比进程更有效地创建/拆除。
SideKiq比Resque效率更高,主要是因为SideKiq工作者是线程,而Resque使用分叉工作者(进程)。
但问题是Ruby on MRI没有本机线程,所以Ruby中的每个Thread都受Global Interpreter Lock(GIL)的限制。有关更多信息,请参阅此Igvita文章:http://www.igvita.com/2008/11/13/concurrency-is-a-myth-in-ruby/
在具有本机线程(如JRuby)的平台上,您可以拥有一个多线程Rails应用程序(在servlet容器中运行),它可能会超出在MRI下运行的相同应用程序。它也可能是Hotspot JVM上的JRuby也可以进行即时性能优化。