about summary refs log tree commit homepage
path: root/lib/rainbows/actor_spawn.rb
diff options
context:
space:
mode:
authorEric Wong <normalperson@yhbt.net>2010-10-22 16:21:03 -0700
committerEric Wong <normalperson@yhbt.net>2010-10-22 16:21:03 -0700
commit180485d49ea858f83ef2a28a9e07224aa514edc7 (patch)
treeb4c649d2118c0010bf3876a49dadfe3e4cbc3f86 /lib/rainbows/actor_spawn.rb
parent41145ed4d335718ac43aec9313b7571a12fe96ee (diff)
downloadrainbows-180485d49ea858f83ef2a28a9e07224aa514edc7.tar.gz
This simplifies and disambiguates most constant resolution
issues as well as lowering our identation level.  Hopefully
this makes code easier to understand.
Diffstat (limited to 'lib/rainbows/actor_spawn.rb')
-rw-r--r--lib/rainbows/actor_spawn.rb42
1 files changed, 20 insertions, 22 deletions
diff --git a/lib/rainbows/actor_spawn.rb b/lib/rainbows/actor_spawn.rb
index 8cb839d..2b42b68 100644
--- a/lib/rainbows/actor_spawn.rb
+++ b/lib/rainbows/actor_spawn.rb
@@ -1,29 +1,27 @@
 # -*- encoding: binary -*-
 
 require 'actor'
-module Rainbows
 
-  # Actor concurrency model for Rubinius.  We can't seem to get message
-  # passing working right, so we're throwing a Mutex into the mix for
-  # now.  Hopefully somebody can fix things for us.  Currently, this is
-  # exactly the same as the ThreadSpawn model since we don't use the
-  # message passing capabilities of the Actor model (and even then
-  # it wouldn't really make sense since Actors in Rubinius are just
-  # Threads underneath and our ThreadSpawn model is one layer of
-  # complexity less.
-  #
-  # This is different from the Revactor one which is not prone to race
-  # conditions within the same process at all (since it uses Fibers).
-  module ActorSpawn
-    include ThreadSpawn
+# Actor concurrency model for Rubinius.  We can't seem to get message
+# passing working right, so we're throwing a Mutex into the mix for
+# now.  Hopefully somebody can fix things for us.  Currently, this is
+# exactly the same as the ThreadSpawn model since we don't use the
+# message passing capabilities of the Actor model (and even then
+# it wouldn't really make sense since Actors in Rubinius are just
+# Threads underneath and our ThreadSpawn model is one layer of
+# complexity less.
+#
+# This is different from the Revactor one which is not prone to race
+# conditions within the same process at all (since it uses Fibers).
+module Rainbows::ActorSpawn
+  include Rainbows::ThreadSpawn
 
-    # runs inside each forked worker, this sits around and waits
-    # for connections and doesn't die until the parent dies (or is
-    # given a INT, QUIT, or TERM signal)
-    def worker_loop(worker) # :nodoc:
-      Const::RACK_DEFAULTS["rack.multithread"] = true # :(
-      init_worker_process(worker)
-      accept_loop(Actor)
-    end
+  # runs inside each forked worker, this sits around and waits
+  # for connections and doesn't die until the parent dies (or is
+  # given a INT, QUIT, or TERM signal)
+  def worker_loop(worker) # :nodoc:
+    Rainbows::Const::RACK_DEFAULTS["rack.multithread"] = true # :(
+    init_worker_process(worker)
+    accept_loop(Actor)
   end
 end