New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add event object subscriptions to AS::Notifications #33451

Merged
merged 6 commits into from Jul 26, 2018

Conversation

Projects
None yet
3 participants
@tenderlove
Member

tenderlove commented Jul 26, 2018

This PR builds on #33449 to allow users to subscribe to event objects from the top level AS::Notifications API. Here is a demonstration of the difference:

Before

ActiveSupport::Notifications.subscribe('wait') do |*args|
  @event = ActiveSupport::Notifications::Event.new(*args)
end

ActiveSupport::Notifications.instrument('wait') do
  sleep 1
end

p @event.duration # => 1000.138

After

ActiveSupport::Notifications.subscribe('wait') do |event|
  @event = event
end

ActiveSupport::Notifications.instrument('wait') do
  sleep 1
end

p @event.duration    # => 1000.138
p @event.allocations # => 7
p @event.cpu_time    # => 0.256
p @event.idle_time   # => 1003.2399

Notice that we don't have to manually construct Event objects anymore. I've found it's incredibly common (in GitHub's codebase anyway) to allocate Event objects in the pattern above, and I think it would be generally helpful if the framework does it for us. In addition, this will give us easy access to performance statistics for every notification event.

/cc @jeremy @eileencodes

tenderlove added some commits Jul 26, 2018

Subscribe to event objects via `subscribe_event`
Fanout notifier can send event objects to subscribers now.  Also moved
`end` lower in the `finish!` method to guarantee that CPU time is
shorter than real time.
Always subscribe to event objects via `AS::Notifications.subscribe`
We don't need to have a special subscribe method for objects.  The
regular `subscribe` method is more expensive than a specialized method,
but `subscribe` should not be called frequently.  If that turns out to
be a hotspot, we can introduce a specialized method.  :)
@tenderlove

This comment has been minimized.

Show comment
Hide comment
@tenderlove

tenderlove Jul 26, 2018

Member

Additionally, this change allows us to hide the constructor of AS::Notification::Event. Since we're passing an object to the block, that object could be anything we want and constructed in any way we want.

Member

tenderlove commented Jul 26, 2018

Additionally, this change allows us to hide the constructor of AS::Notification::Event. Since we're passing an object to the block, that object could be anything we want and constructed in any way we want.

@eileencodes

I think this warrants a changelog entry but otherwise looks good here 👍

@tenderlove

This comment has been minimized.

Show comment
Hide comment
@tenderlove

tenderlove Jul 26, 2018

Member

I think this warrants a changelog entry

Good call, I will add it. 😊

Member

tenderlove commented Jul 26, 2018

I think this warrants a changelog entry

Good call, I will add it. 😊

@georgeclaghorn

This comment has been minimized.

Show comment
Hide comment
@georgeclaghorn

georgeclaghorn Jul 26, 2018

Member

I've found it's incredibly common (in GitHub's codebase anyway) to allocate Event objects in the pattern above, and I think it would be generally helpful if the framework does it for us.

We do this in Basecamp, too. 👍

Member

georgeclaghorn commented Jul 26, 2018

I've found it's incredibly common (in GitHub's codebase anyway) to allocate Event objects in the pattern above, and I think it would be generally helpful if the framework does it for us.

We do this in Basecamp, too. 👍

@tenderlove

This comment has been minimized.

Show comment
Hide comment
@tenderlove

tenderlove Jul 26, 2018

Member

Urgh. I can't do feature detection on the block because:

irb(main):017:0> lambda { |x, **args| }.arity
=> -2
irb(main):018:0> proc { |x, **args| }.arity
=> 1
irb(main):002:0> (foo { |x| }).arity
=> 1
irb(main):003:0> (foo { |x, **args| }).arity
=> 1

Thinking about how to detect this

Member

tenderlove commented Jul 26, 2018

Urgh. I can't do feature detection on the block because:

irb(main):017:0> lambda { |x, **args| }.arity
=> -2
irb(main):018:0> proc { |x, **args| }.arity
=> 1
irb(main):002:0> (foo { |x| }).arity
=> 1
irb(main):003:0> (foo { |x, **args| }).arity
=> 1

Thinking about how to detect this

tenderlove added some commits Jul 26, 2018

@tenderlove tenderlove merged commit 3ea2857 into master Jul 26, 2018

0 of 3 checks passed

codeclimate Code Climate is analyzing this code.
Details
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/travis-ci/push The Travis CI build is in progress
Details

@tenderlove tenderlove deleted the event-object-subscription branch Jul 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment