Skip to content
Eventable is an easy to use and understand event model; it's the simplest way to add fine-grain events to your classes.
Ruby Shell
Latest commit 316a8e7 Sep 10, 2014 Mike Bethany Seriously - ignore the example
Failed to load latest commit information.
autotest Updated specs Sep 10, 2014
lib Updated specs Sep 10, 2014
spec Updated specs Sep 10, 2014
.gitignore now ignore example Sep 10, 2014
Gemfile Updated specs Sep 10, 2014
LICENSE.txt Updated specs Sep 10, 2014
README.markdown Updated specs Sep 10, 2014
Rakefile Updated specs Sep 10, 2014
eventable.gemspec Updated specs Sep 10, 2014



An incredibly simple way to add events to your classes.


Provides an easy to use and understand event model. Other systems did way too much for my needs: I didn't need to monitor network IO ports, I didn't want a central loop that polled IO, I just wanted a simple way to add real, non-polled events to a class and to register other classes to listen for those events.

If you want a simple way to add events to your classes without a bunch of other unrelated IO stuff this is the solution for you. (If you want to monitor IO events check out EventMachine)

You might be saying, "What about Observable? Why not just use that?" The problem with observable is that it saves a reference to the observing object. If you drop and add a bunch of observers without removing them from the observed object you've got the potential for a huge memory leak (depending on the size of your listeners of course).

With Eventable you don't have to worry about memory leaks because Eventable only make a reference to the listening object when it needs to talk to it. When it's done the reference goes out of scope and can be garbage collected.

Eventable will even automatically remove registered listeners when they get garbage collected. You can set up a listener and not worry about removing your event hook yourself; it's done for you.

Eventable also allows for more fine-grain control than Observable. You can register for specific events instead of just saying, "Hey, let me know when anything changes."

Concurrency considerations

Events and threads do not scale well past a certain point but that's OK; they aren't meant to. They are meant for fast, simple communication beteen processes not large distributed processes like serving websites on massive server farms. If you need a solution that scales well to large distributed systems check out the Actor concurrency model.


$ gem install eventable

Usage Instructions

  • Include the module
  • Important: If you have an initialize method super must be the first line of that method (see below). If you don't have an initialize method you don't have to add one. Super is called automatically for you.
  • Add an event, e.g. event :your_event
  • Fire the event when it should be fired: fire_event(:your_event)

To reiterate you must call super in your initialize method or Eventable won't work and you'll get an error. Eventable needs to create a mutex to make it thread safe, if you don't call super the mutex variable won't be created.


This example shows the basics of using Eventable to add an event to a class and listen for that event. (Without threading it's a bit pointless):

require 'eventable'

class EventClass
  include Eventable

  # This is all you have to do to add an event (after you include Eventable)
  event :stuff_happens

  # There's no initialize method so you do
  # not have to worry about calling super.

  # don't name your method fire_event, that's taken
  def do_event
    puts "firing :stuff_happens"
    # And this is all you have to do to make the event happen
    fire_event(:stuff_happens, rand(1000))


class ListenClass

  def stuff_happened(stuff)
    puts "stuff happened callback: #{stuff}"


# Create an instance of a class that has an event
evented   =

# Create a class that listens for that event
listener  =

# Register the listener with the instance that will have the event
evented.register_for_event(event: :stuff_happens, listener: listener, callback: :stuff_happened)

# We'll just arbitrarilly fire the event to see how it works

# Wait just to be sure you see it happen

=> firing :stuff_happens
=> stuff happened callback: 575

This example shows you how you might actually use it in a multi-threaded environment but is a lot harder to read because of all the debug code:

require 'eventable'

class EventedClass
  include Eventable
  event :stuff_happens
  event :other_stuff_happens

  def initialize
    # If you don't call super Eventable will raise an error
    super # <= VERY important, comment this out to see the error
    # do your initialize stuff

  def make_stuff_happen(parent_id)
    # You handle concurrency however you want, threads or fibers, up to you.{
      puts "firing :stuff_happens"
      fire_event(:stuff_happens, {:parent_id=>parent_id, :some_value => rand(1000)})

  def start_other_stuff_happening {
      5.times do 
        puts "firing :other_stuff_happens"


class ListenerClass

  def initialize(some_object)
    @some_thing = some_object
    @some_thing.register_for_event(event: :stuff_happens, listener: self, callback: :stuff_happened)

  def do_somestuff(parent_id, times=6)
    # I wrapped this in a thread to show it works cross threaded{
      id = rand(1000)
      times.times do
        puts "[#{parent_id}, #{id}]: do_somestuff"

  def stuff_happened(stuff)
    puts "[#{stuff[:parent_id]}] stuff_happened callback: #{stuff[:some_value]}"

  def other_stuff_happened
    puts "[n/a] other_stuff_happened callback: n/a"


# Now show it running
evented =

# You can inject the evented class
listener =

# or attach to events outside of a listener class
evented.register_for_event(event: :other_stuff_happens, listener: listener, callback: :other_stuff_happened)

# Start firing off the events

(1..3).each do |index|
  puts "[#{index}] did some stuff, sleeping"
  puts "[#{index}] slept"

puts "all done"

Version History

2014.09.10 Ver: 0.2.1

  • Verified to work with Ruby 2.1
  • Updated specs to RSpec 2.99
  • Updated dependencies and author links.

2014.03.26 Ver: 0.2.0


Updating for Ruby 2.x

2011.07.05 Ver: 0.1.4


  • Added running specs to rake tasks (Colin Gemmell)

Bug fixes:

  • Did not accept initialization parameters so caused errors if your class inherited from another class that needed them. (Paul Strong)

Ver: 0.1.3


Callbacks are now threaded:
This patches one of the last concurrency issues; if a callback takes a long time or hangs it won't affect any other callbacks or events that need to fire.

It's your responsiblity to make sure your callback works, as long as it does the callback thread will go out of scope (unless you retain it) and everyone is happy.

Ver: 0.1.2

Design updates/fixes:

  • Renamed most instance variables to help avoid name collisions.
  • Threadsafe mutex creation. Make sure you call super in your class's initialize method! (Robert Klemme)

Ver: 0.1.1


  • If events fired specifically returns true and returns false if it can't for whatever reason (e.g. no listeners registered).


  • Throws error if event is fired and no listeners are registered (Benjamin Yu)
  • Workaround for RubyGems pre 1.8.3 date bug that locks up all of RubyGems (Benjamin Yu)

Ver: 0.1.0
Went crazy and just completely wrapped all calls that modify or read callbacks cache with an instance mutex.

From what I understand locks are really expensive in Ruby so I'll need to clean this up and do some real performance testing.

Note: Releasing just to stop from showing last beta instead of newest beta when there are only --pre versions available of a gem. I get why they do it, but it's annoying to have people downloading beta 1 when you're really on beta 2. Plus I need to start using it myself...

Ver: 0.1.0.beta2

  • Wrapped #_id2ref call in begin...rescue block. (Evan Phoenix)
  • Added thread synchronization to calls that modify or read callbacks cache.

Ver: 0.1.0.beta1
Completely redesigned from naive first attempt.

Added features

Now includes RSpecs.

Garbage collection safe:

  • Won't keep references to listeners open.
  • Automatically removes garbage collected listeners from event notifications.

Ver: 0.0.1.alpha
Just wrote it as a proof of concept.

Patches/Pull requests

  • Fork the project.
  • Make your feature addition or bug fix (do not alter whitespace unless that is a bug!)
  • Add RSpecs for the fix/feature. If you don't have specs I can't add it.
  • Commit your changes. (do not change the rakefile, version, or history)
  • Send a pull request. I respond to pull request very, very quickly.
Something went wrong with that request. Please try again.