mikbe / eventable Goto Github PK

$ irb
ruby-1.9.2-p180 :001 > require 'eventable'
 => true 
ruby-1.9.2-p180 :002 > 
ruby-1.9.2-p180 :003 >   class EventClass
ruby-1.9.2-p180 :004?>     include Eventable
ruby-1.9.2-p180 :005?>   
ruby-1.9.2-p180 :006 >       # This is all you have to do to add an event (after you include Eventable)
ruby-1.9.2-p180 :007 >       event :stuff_happens
ruby-1.9.2-p180 :008?>   
ruby-1.9.2-p180 :009 >       # don't name your method fire_event, that's taken
ruby-1.9.2-p180 :010 >       def do_event
ruby-1.9.2-p180 :011?>         puts "firing :stuff_happens"
ruby-1.9.2-p180 :012?>         # And this is all you have to do to make the event happen
ruby-1.9.2-p180 :013 >           fire_event(:stuff_happens, rand(1000))
ruby-1.9.2-p180 :014?>       end
ruby-1.9.2-p180 :015?>   
ruby-1.9.2-p180 :016 >     end
 => nil 
ruby-1.9.2-p180 :017 > 
ruby-1.9.2-p180 :018 >   # Create an instance of a class that has an event
ruby-1.9.2-p180 :019 >   evented   = EventClass.new
 => #<EventClass:0x1bad00> 
ruby-1.9.2-p180 :020 > # We'll just arbitrarilly fire the event to see how it works
ruby-1.9.2-p180 :021 >   evented.do_event
firing :stuff_happens
NoMethodError: undefined method `synchronize' for nil:NilClass
    from ~/.rvm/gems/ruby-1.9.2-p180@develop/gems/eventable-0.1.0/lib/eventable/eventable.rb:36:in `fire_event'
    from (irb):13:in `do_event'
    from (irb):21
    from ~/.rvm/rubies/ruby-1.9.2-p180/bin/irb:16:in `<main>'
ruby-1.9.2-p180 :022 > 

This is because line 36 of eventable.rb tries to synchronize on a mutex that doesn't exist. The mutex is created in the registration of a first event.

Possible fix is to guard the synchronize call with a nil check?

The next thing, I'm not sure about because I'm unfamiliar with underlying language implementation in the VMs. This is me mostly just pondering because of the likelihood of this happening seems very small.

Also, could there exist a possible problem (seems very unlikely, but theoretically possible) when multiple threads attempt to register listeners at the same time on an event class that has had no previous registered listeners. The call:

    @mutex ||= Mutex.new

I don't think the ||= operator is atomic??? Thus it possibly be that thread A sees that @mutex is nil so it will create a new mutex. But before the assignment, that thread is immediately interrupted by thread B who is also registering an event. It goes past this line, creating a new mutex. Then thread A runs again, thus completing the mutex assignment. They both run code in the synchronized block... And proceeds to do unpredictable things in the ||= type assignments in the protected code w.r.t the @callbacks.

If two threads using the same instance of an evented class call methods that create the @mutex variable then we have a collision. @mutex needs to be protected some how. Either by creating it when the class is instantiated or use a semaphore around its own creation.

Here's an example of how this is possible:
https://gist.github.com/1031308

Deleted - Asker did not understand Eventable's concurrency model.

@mutex could easily be used by an inheriting class. Rename @mutex variable (and any other instance variables that are generic).

$ ruby --version
ruby 1.9.2p180 (2011-02-18 revision 30909) [i386-darwin9.8.0]

$ gem --version
1.8.2

$ gem install eventable
Fetching: eventable-0.1.0.gem (100%)
Invalid gemspec in [/.rvm/gems/ruby-1.9.2-p180@develop/specifications/eventable-0.1.0.gemspec]: invalid date format in specification: "2011-06-06 00:00:00.000000000Z"
ERROR: While executing gem ... (NoMethodError)
undefined method `name' for nil:NilClass
[]
$

Now this error'd gemspec essentially denies the ruby system from being able to boot.

Removing the time segment from the gemspec seems to fix the problem.

Event callbacks are currently blocking so if one callback locks up it breaks all the following callbacks and the evented class itself locks up.

Callbacks should be threaded/fibered to avoid this.