[Eventmachine-talk] eventable experiment and application-level

Chuck Remes
Wed, 13 Feb 2008 14:02:15 -0000

On Feb 13, 2008, at 2:40 PM, James Tucker wrote:

> 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)


That looks pretty reasonable. I can use that as a guideline. Thanks!

> [snip]
>
> 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.

This is the rub right here. If I set a timer task to run very
frequently, if there is no work to perform then this essentially
devolves into polling. If I run the timer task once per second,
pending events could wait a "long" time before being processed;
throughput would suck.

I want to be able to post events to the reactor core and have it
handle the dispatching for me. What would you recommend? If I''m
missing something obvious or already answered, no need to be gentle. :-)

cr