线程还是 DRb？
我需要在 Ruby 中让程序有 2 个（或者可能是 3 个）连续运行的“方面”——一个通信线程、一个渲染线程，也许还有一个缓存线程。
这个想法是渲染线程显示幻灯片（其定义是从文件中读取的），并且所有幻灯片都由通信线程从远程 HTTP 服务器检索。渲染必须连续且不间断（因此可能需要缓存）。该文件可能会在程序的生命周期中发生变化，因此需要重新解析（即时）。
我想在“方面”之间发送消息，例如当通信线程获得节目的整个“章节”时，渲染线程可以在等待整个节目下载之前启动，等等。
我应该使用 Ruby 线程还是 DRb？如何在线程之间传递消息？
感谢您的任何反馈！
I need to have 2 (or maybe 3) continuously running "facets" of a program in Ruby - a communications thread, a render thread and maybe a caching thread.
The idea is the rendering thread shows a slide-show (whose definition is read from file) and all slides are retrieved from a remote HTTP server by the communications thread. The rendering must be continuous and without stops (hence the probable need for caching). The file may change over the course of the program's lifetime and thus need re-parsing (on the fly).
I would like to send messages between the "facets" like when the comms thread gets a whole "chapter" of the show, the render thread could start before waiting for the whole show to be downloaded, for example, and so on.
Should I use Ruby threads or DRb? How can I pass messages between the threads?
Thanks for any feedback!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
保持简单的开始——永远是最好的建议。从两个线程开始，看看性能是否满足您的需要。您可以使用条件变量或简单的互斥体来同步检索到的章节列表。您可能会遇到欠载问题 - 没有可用于渲染的章节，但您至少将拥有一个仅使用核心 Ruby 的可行解决方案的框架。
然后一定要寻找提供其他可能性的解决方案。除了 DRb 之外，您还应该查看 EventMachine（了解阅读章节时可能需要的异步功能）和 RabbitMQ，以了解消息系统提供的更通用、更松散的耦合。
从小事做起，不要试图行动得太快。对于任何担心 Ruby 线程的人，我正在运行一个小型报告渲染客户端，侦听 RabbitMQ 队列。客户端使用四个线程来渲染（谷歌）图表、发送警报并自动重置各种队列（收集几个小时的数据后）。一切都很好！
克里斯
Keep it simple to start with - always the best advice. Start with just two threads and see if the performance is what you need. You can use condition variable or simple Mutexes to synch around a list of retrieved chapters. You'll possibly get the problem of underrun - no chapter available for rendering but you'll at least have the bones of a workable solution using nothing more than core Ruby.
Then by all means look at solutions which offer other possibilities. Apart from DRb, you should also look at EventMachine (for the asynch capabilities you may need when reading chapters) and RabbitMQ for the more general and looser coupling that a messaging system offers.
Start small and don't try to move too fast. For anyone who has concerns about Ruby threads, I'm running a small report rendering client listening on a RabbitMQ queue. The client uses four threads for rendering the (google) graphs, sending alerts and automatically resetting various queues (after several hours of data have been gathered). All works great!
Chris