您的主循环正在控制参与者/应用程序的线程。
您的程序所做的只是生成后台进程，但从不运行它们。您需要在循环中使用 sleep 纯粹是为了让后台线程引起注意。
像这里那样让无条件循环产生无限的后台进程通常不是一个好主意。应该有一个延迟，或者在那里放置一个条件语句......否则你只会有一个无限循环产生永远不会被调用的东西。
这样想：如果您将puts "looping" 放在循环中，而您看不到Running in the background ...您将一遍又一遍地看到looping。
方法 #1：使用 every 或 after 块。
解决此问题的最佳方法不是在loop 中使用sleep，而是使用after 或every 块，如下所示：
every(0.1) {
on_background
}
或者最重要的是，如果您想确保进程在再次运行之前完全运行，请改用after：
def run_method
@running ||= false
unless @running
@running = true
on_background
@running = false
end
after(0.1) { run_method }
end
在async 中使用loop 不是一个好主意，除非完成了某种流控制，或者像@server.accept 这样的阻塞进程...否则它只会占用100% 的CPU没有正当理由的核心。
顺便说一句，您也可以使用now_and_every 和now_and_after...这将立即运行该块，然后在您想要的时间后再次运行它。
使用every 显示在此要点中：
我认为理想的情况：
这是一个粗略但立即可用的示例：
require 'celluloid/current'
class Indefinite
include Celluloid
INTERVAL = 0.5
ONE_AT_A_TIME = true
def self.run!
puts "000a Instantiating."
indefinite = new
indefinite.run
puts "000b Running forever:"
sleep
end
def initialize
puts "001a Initializing."
@mutex = Mutex.new if ONE_AT_A_TIME
@running = false
puts "001b Interval: #{INTERVAL}"
end
def run
puts "002a Running."
unless ONE_AT_A_TIME && @running
if ONE_AT_A_TIME
@mutex.synchronize {
puts "002b Inside lock."
@running = true
on_background
@running = false
}
else
puts "002b Without lock."
on_background
end
end
puts "002c Setting new timer."
after(INTERVAL) { run }
end
def on_background
if ONE_AT_A_TIME
puts "003 Running background processor in foreground."
else
puts "003 Running in background"
end
end
end
Indefinite.run!
puts "004 End of application."
如果ONE_AT_A_TIME 是true，这将是它的输出：
000a Instantiating.
001a Initializing.
001b Interval: 0.5
002a Running.
002b Inside lock.
003 Running background processor in foreground.
002c Setting new timer.
000b Running forever:
002a Running.
002b Inside lock.
003 Running background processor in foreground.
002c Setting new timer.
002a Running.
002b Inside lock.
003 Running background processor in foreground.
002c Setting new timer.
002a Running.
002b Inside lock.
003 Running background processor in foreground.
002c Setting new timer.
002a Running.
002b Inside lock.
003 Running background processor in foreground.
002c Setting new timer.
002a Running.
002b Inside lock.
003 Running background processor in foreground.
002c Setting new timer.
002a Running.
002b Inside lock.
003 Running background processor in foreground.
002c Setting new timer.
如果ONE_AT_A_TIME 是false，这将是它的输出：
000a Instantiating.
001a Initializing.
001b Interval: 0.5
002a Running.
002b Without lock.
003 Running in background
002c Setting new timer.
000b Running forever:
002a Running.
002b Without lock.
003 Running in background
002c Setting new timer.
002a Running.
002b Without lock.
003 Running in background
002c Setting new timer.
002a Running.
002b Without lock.
003 Running in background
002c Setting new timer.
002a Running.
002b Without lock.
003 Running in background
002c Setting new timer.
002a Running.
002b Without lock.
003 Running in background
002c Setting new timer.
002a Running.
002b Without lock.
003 Running in background
002c Setting new timer.
您需要更多的“事件”而不是“线程”才能正确发出任务并保留范围和状态，而不是在线程/参与者之间发出命令...这是 every 和 after 块提供的。除此之外，无论哪种方式都是很好的做法，即使您没有要处理的Global Interpreter Lock，因为在您的示例中，您似乎没有处理阻塞进程。如果你有一个阻塞进程，那么一定会有一个无限循环。但是，由于您最终会在处理一个任务之前生成无限数量的后台任务，因此您需要像您的问题一样使用sleep，或者完全使用不同的策略，并使用every和after 这就是Celluloid 本身在处理任何类型的套接字上的数据时鼓励您操作的方式。
方法 #2：使用递归方法调用。
这刚刚出现在 Google 网上论坛中。下面的示例代码实际上将允许执行其他任务，即使它是一个无限循环。
这种方法不太理想，因为它可能会产生更多开销，从而产生一系列纤维。
def work
# ...
async.work
end
问题 #2：Thread 与 Fiber 行为。
第二个问题是为什么以下方法会起作用：loop { Thread.new { puts "Hello" } }
这会产生无限数量的进程线程，这些线程由RVM 直接管理。即使您正在使用的RVM 中有Global Interpreter Lock...这仅意味着没有使用green threads，它们由操作系统本身提供...而是由进程本身处理。进程的 CPU 调度程序会毫不犹豫地运行每个Thread。在这个例子中，Thread 运行得非常快，然后就死掉了。
与async 任务相比，使用了Fiber。那么在默认情况下发生了什么：
- 进程开始。
- Actor 已实例化。
- 方法调用调用循环。
- 循环调用
async 方法。
-
async 方法将任务添加到邮箱。
- 邮箱未调用，循环继续。
- 另一个
async 任务被添加到邮箱。
- 这将无限继续。
以上是因为循环方法本身是一个Fiber调用，它永远不会被挂起（除非sleep被调用！），因此添加到邮箱的附加任务永远不会调用一个新的@ 987654383@。 Fiber 的行为与 Thread 不同。这是讨论差异的很好的参考资料：
问题 #3：Celluloid 与 Celluloid::ZMQ 的行为。
第三个问题是为什么include Celluloid 的行为不同于Celluloid::ZMQ ...
这是因为 Celluloid::ZMQ 使用基于反应器的事件邮箱，而 Celluloid 使用基于条件变量的邮箱。
阅读有关流水线和执行模式的更多信息：
这就是两个例子之间的区别。如果您对这些邮箱的行为有其他疑问，请随时在Google Group 上发帖……您面临的主要动态是GIL 与Fiber 与Thread 与Thread 交互的独特性质.Reactor行为。
您可以在此处阅读有关反应器模式的更多信息：
并在此处查看Celluloid::ZMQ 使用的具体反应器：
那么在事件邮箱场景中发生的情况是，当sleep 被命中时，这是一个阻塞调用，这会导致反应器移动到邮箱中的下一个任务。
而且，这对于您的情况来说是独一无二的，Celluloid::ZMQ 使用的特定反应器正在使用一个永恒的 C 库......特别是 0MQ 库。该反应器在您的应用程序外部，其行为与 Celluloid::IO 或 Celluloid 本身不同，这也是行为发生与您预期不同的原因。
多核支持替代方案
如果维护状态和范围对您来说并不重要，如果您使用不限于一个操作系统线程的jRuby 或Rubinius，与使用具有Global Interpreter Lock 的MRI 相比，您可以实例化更多不止一个演员，并在演员之间同时发出async 调用。
但我的拙见是使用非常高频率的计时器会更好地为您服务，例如我的示例中的0.001 或0.1，这对于所有意图和目的来说似乎都是即时的，但也允许演员线程有足够的时间来切换光纤并在邮箱中运行其他任务。