diff options
author | Eric Wong <normalperson@yhbt.net> | 2010-10-22 16:21:03 -0700 |
---|---|---|
committer | Eric Wong <normalperson@yhbt.net> | 2010-10-22 16:21:03 -0700 |
commit | 180485d49ea858f83ef2a28a9e07224aa514edc7 (patch) | |
tree | b4c649d2118c0010bf3876a49dadfe3e4cbc3f86 /lib/rainbows/actor_spawn.rb | |
parent | 41145ed4d335718ac43aec9313b7571a12fe96ee (diff) | |
download | rainbows-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.rb | 42 |
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 |