From cremes.devlist at mac.com  Wed Apr  2 16:31:06 2008
From: cremes.devlist at mac.com (Chuck Remes)
Date: Wed, 2 Apr 2008 15:31:06 -0500
Subject: [Revactor-talk] Actors Exiting
In-Reply-To: <c7e6b2b00803311524r53eb357cs369ddcb66997d332@mail.gmail.com>
References: <a2830e5b0803291847i160daf8aub093ec77ee2bd6a7@mail.gmail.com>
	<c7e6b2b00803301732u42df0c8eye7f270e42a6f353b@mail.gmail.com>
	<F7CBBC92-DAB6-4271-A6B2-F8696CC98C6B@codefluency.com>
	<c7e6b2b00803310903k40537416p782ae59f4ccd1b15@mail.gmail.com>
	<96785B30-0686-4500-892C-2935E7702B8D@mac.com>
	<7F131D8C-59D2-4080-87C5-FF4ED35D1600@codefluency.com>
	<c7e6b2b00803311524r53eb357cs369ddcb66997d332@mail.gmail.com>
Message-ID: <B35751AB-631F-4B46-BE20-55A72918F16B@mac.com>


On Mar 31, 2008, at 5:24 PM, Tony Arcieri wrote:

> On Mon, Mar 31, 2008 at 3:54 PM, Bruce Williams  
> <bruce at codefluency.com> wrote:
> Specifically it would be interesting to see more non-IO related  
> examples; while Revactor IO is compelling, it's the actor messaging  
> ala Erlang-style mailboxes (replacing traditional Ruby threads +  
> mutexes/queues) that really drew me in.
>
> All right, point taken: more examples are needed.
>
> What's an example of something non-I/O related that you would you  
> like to see an example of?

I can't speak for Bruce, but I'd like to see how to write the game of  
"telephone" using Actors. While this might appear boring (and is), it  
would demonstrate a simple pattern for partitioning long-running  
calculations so they don't starve all the other actors running in  
their own green thread. In effect each message pass to the next  
mailbox is a "thread yield" so someone else can get some work done, or  
the main reactor can process more incoming events.

Alternately, I'd like to see the creation of a Supervisor Actor that  
registers for its children's exceptions and knows how to restart them  
if one faults. That would be interesting to see how to do with this lib.

cr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/revactor-talk/attachments/20080402/075714e5/attachment.html 

From tony at medioh.com  Wed Apr  2 17:02:24 2008
From: tony at medioh.com (Tony Arcieri)
Date: Wed, 2 Apr 2008 15:02:24 -0600
Subject: [Revactor-talk] Actors Exiting
In-Reply-To: <B35751AB-631F-4B46-BE20-55A72918F16B@mac.com>
References: <a2830e5b0803291847i160daf8aub093ec77ee2bd6a7@mail.gmail.com>
	<c7e6b2b00803301732u42df0c8eye7f270e42a6f353b@mail.gmail.com>
	<F7CBBC92-DAB6-4271-A6B2-F8696CC98C6B@codefluency.com>
	<c7e6b2b00803310903k40537416p782ae59f4ccd1b15@mail.gmail.com>
	<96785B30-0686-4500-892C-2935E7702B8D@mac.com>
	<7F131D8C-59D2-4080-87C5-FF4ED35D1600@codefluency.com>
	<c7e6b2b00803311524r53eb357cs369ddcb66997d332@mail.gmail.com>
	<B35751AB-631F-4B46-BE20-55A72918F16B@mac.com>
Message-ID: <c7e6b2b00804021402x1c831667o380b4f23fe2a8918@mail.gmail.com>

On Wed, Apr 2, 2008 at 2:31 PM, Chuck Remes <cremes.devlist at mac.com> wrote:

> I can't speak for Bruce, but I'd like to see how to write the game of
> "telephone" using Actors. While this might appear boring (and is), it would
> demonstrate a simple pattern for partitioning long-running calculations so
> they don't starve all the other actors running in their own green thread. In
> effect each message pass to the next mailbox is a "thread yield" so someone
> else can get some work done, or the main reactor can process more incoming
> events.
>

Here's an example for passing a message around a ring of Actors, but it
probably isn't what you're after:

http://revactor.rubyforge.org/svn/trunk/examples/ring.rb

For long running calculations, you'll need to farm them out into separate
native threads (Ruby 1.9 no longer has green threads).  This is as simple
as:

Thread.new(Actor.current) { |interested_party| interested_party <<
long_running_calculation }

Actor.receive do |filter|
  filter.when(Object) { |long_running_result| ... }
end

Unfortunately, a caveat: messaging between threads is presently buggy and
only works sporadically.  It's something I intend on getting rock solid in
the next release.


> Alternately, I'd like to see the creation of a Supervisor Actor that
> registers for its children's exceptions and knows how to restart them if one
> faults. That would be interesting to see how to do with this lib.
>

Here's a linking / exit trapping example:

http://revactor.rubyforge.org/svn/trunk/examples/trap_exit.rb

You can use linked  basic supervisor behavior to this:

require 'revactor'

class Crashy
  extend Actorize

  def initialize
    Actor.receive do |filter|
      filter.when(:die) { raise "Aieeee!" }
    end
  end
end

class CrashySupervisor
  extend Actorize

  def initialize
    Actor.current.trap_exit = true
    spawn_crashy

    loop do
      Actor.receive do |filter|
        filter.when(Tuple[:exit]) do |_, actor, error|
          puts "Crashy actor #{actor} died: #{error}"
          puts "Restarting..."
          spawn_crashy
        end
      end
    end
  end

  def spawn_crashy
    Actor[:crashy] = Crashy.spawn_link
  end
end

CrashySupervisor.spawn
Actor[:crashy] << :die
Actor.sleep 5 # you'd hopefully be doing something more useful than
sleeping here...

-- 
Tony Arcieri
medioh.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/revactor-talk/attachments/20080402/60f05ecb/attachment.html