Skip to content
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

Fix a potential memory leak in schedulePeriodically #2642

Merged
merged 3 commits into from
Feb 10, 2015

Conversation

zsxwing
Copy link
Member

@zsxwing zsxwing commented Feb 9, 2015

There is a potential memory leak in schedulePeriodically that may keep a reference to action after unsubscribe.

Because mas.set is called after schedule, it may replace a new Subscription (created in recursiveAction) with the old one. Therefore, unsubscribe won't be able to unsubscribe the new Subscription and will keep the reference to action until the period time elapses.

This PR fixed it by calling mas.set before schedule.

@@ -119,11 +120,17 @@ public void call() {
if (!mas.isUnsubscribed()) {
action.call();
long nextTick = startInNanos + (++count * periodInNanos);
mas.set(schedule(this, nextTick - TimeUnit.MILLISECONDS.toNanos(now()), TimeUnit.NANOSECONDS));
SerialSubscription s = new SerialSubscription();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there is no need to change this here: the initial SerialSubscription can safely overwritted by the result of the schedule as it is not reentrant.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean if period is large, the new Subscription created in the next action won't be able to replace the one here, and if period is small, the leak won't be a problem?

Just to make sure we are in the same page.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. I mean once the action is executed on the worker, each invocation of call is guaranteed to be serial, therefore, there is no need to have another level of SerialSubscription indirection.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha. Forgot it...

@akarnokd akarnokd added the Bug label Feb 9, 2015
@akarnokd
Copy link
Member

akarnokd commented Feb 9, 2015

It is functionally mergeable, but you could have used MultipleAssignmentSubscription s = ... and saved an import.

akarnokd added a commit that referenced this pull request Feb 10, 2015
Fix a potential memory leak in schedulePeriodically
@akarnokd akarnokd merged commit d1034ed into ReactiveX:1.x Feb 10, 2015
@zsxwing zsxwing deleted the fix-memory-leak branch January 12, 2016 21:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants