Ruby Ractor 与 Python 的 MultiProcessing 模块相同吗？

Question

Ruby 3.0 版本引入了 Ractor 以及它们在示例中的表示方式，让人想起了 Python 的 MultiProcessing 模块。

所以...

1. Ruby 的 Ractor 是否只是伪装的多个进程，而 GIL 仍然统治着线程？

2. 如果不是，您能否提供一个示例，其中 Ractor 在速度和通信延迟方面都比多处理更具优势？

3. Ractor 能否像 C/C++ 线程一样快且延迟低？

谢谢

Answer 1

1. Ruby 的 Ractor 是否只是伪装的多个进程，而 GIL 仍然统治着线程？

Ractor 规范没有规定任何特定的实现策略。它肯定没有规定实现者必须使用操作系统进程。事实上，虽然这将是一个非常简单的实现，因为操作系统为您完成了所有艰苦的工作，但它也将是一个非常愚蠢的实现，因为 Ractor 是轻量级的，而操作系统进程通常不是。

所以，我希望每个实施者都会选择自己最有效的实施策略。例如，我希望 TruffleRuby 和 JRuby 的实现基于 Kilim 或 Project Loom 等，Opal 的实现基于 WebWorkers、Realms 和 Promises，Artichoke 的实现基于 Actix、Riker 或 Axiom，也许还有 MRuby的实现由于 MRuby 注重简单性，因此实现甚至可能基于操作系统进程。

就在此时此刻，还不存在任何可用于生产的 Ractor 实现。事实上， Ractor不可能有生产就绪的实现，因为 Ractor 规范本身仍处于实验阶段，因此尚未最终确定。

目前唯一存在的实现是 Koichi Sasada 的原始原型，目前随 YARV 3.0.0 一起提供。此实现不将Ractor 实现为进程，而是将它们实现为操作系统线程。YARV 没有 GIL，但它有每个 Ractor GVL。因此，一个 Ractor 只能同时运行一个线程，但多个 Ractor 可以同时运行一个线程。

然而，这并不是一个非常优化的实现，只是一个原型。我希望 TruffleRuby 或 JRuby 的实现没有任何类型的全局锁。他们以前从未有过，而且 Ractor 不共享任何数据，因此一开始就没有什么可以锁定的。

2. 如果不是，您能否提供一个示例，其中 Ractor 在速度和通信延迟方面都比多处理更具优势？

这种比较没有多大意义。首先，Ractor 是一个具有潜在多种实现的规范，而据我了解，Python 的多处理模块只是启动多个 Python 解释器的一种方式。

其次，Ractor 是一种具有特定语言语义的语言特征。

3. Ractor 能否像 C/C++ 线程一样快且延迟低？

不太清楚你的意思是什么。C 没有线程，所以询问 C 线程是没有意义的。C++ 有线程，但就像 Ractor 一样，它们只是一个具有多种可能实现的规范。它仅取决于 Ractor 和 C++ 线程的特定实现。

当然可以使用线程来实现 Ractor。当前的 YARV 原型就是证明。