[Eventmachine-talk] eventable experiment and application-level

James Tucker
Wed, 13 Feb 2008 12:40:14 -0000

I took a look at Eventable when I needed internal event processing, or
at least, a centralized ''listen for event'' system.

It''s possible to do this all kinds of ways, I simply use a hash with
some syntax sugar tacked on.

I didn''t use Eventable if i remember correctly, because:

a) I had no idea if it was being used somewhere else
b) the implementation is either missing or outside of ruby?
c) There is no way to remove event handlers
d) Some of our handlers for some apps are growing to resemble
something that plays a logical part not too far detached from a
''controller'' from an MVC stack.

So I defined everything ruby side, using as I say, a hash plus some
syntax sugar.

For the implementations with fatter handlers (something larger than a
proc or Method to call), I also provided a mechanism for auto-
discovering the handlers. (At this point, it really does start to
resemble controllers).

A simple starter:


Handlers = Hash.new { |h,k| h[k] = [] }

class <<Handlers
   def handle(name, *args)
     self[name].each do |h|
       begin
         h.call *args
       rescue
       end
     end
   end
end

Handlers[:my_event] << proc { puts "my event occurred" }

Handlers.handle(:my_event)

pr = proc { |arg| puts "event2: #{arg}" }
Handlers[:my_event2] << pr

Handlers.handle(:my_event2, ''test'')
Handlers[:my_event].delete(pr)

:"salt to taste."

(I knocked that out in the mail, so if there''s a mistake please feel
free to ask, it should just work in irb)

Monkey patch your handler collection (the array in hash.new) for
syntax like Handlers[:my_event].fire(*args), should you so desire.

You can use any old objects for indexes, and anything that implements
''call'' as a callback on the event (procs, methods, etc).

It''s possibly worth noting that there''s no EventMachine code
in there.
You can easily wrap this up in deferrables and defer calls, make event
processing queues, wrap short jobs in simple timer stacks for ''lightly
deferred'' scheduling, etc. Keeping it real simple helps a lot.

I explicitly catch stuff in the handlers, when processing the list;
you often don''t want to leave exceptions that raise up the stack, and
it''s even worse in a defer or timer, or some place without an errback
(i.e. where the exception would hit the EM reactor core).

On 13 Feb 2008, at 17:36, Chuck Remes wrote:

> While searching through some old threads on this list, I ran across
> some discussions from May 2006 regarding the addition of application-
> level events via a new class called Eventable. I took a look through
> the svn repository and saw the core-model-1 through core-model-3
> experiments, but it doesn''t looks like any of this code ever made
it
> to trunk.
>
> Is there still a plan to allow posting and receiving internally-
> defined events or is EM sticking with only processing IO events?
>
> cr
>
> _______________________________________________