Skip to content

Amb + Backpressure #1533

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

Merged
merged 2 commits into from
Jul 30, 2014
Merged

Conversation

benjchristensen
Copy link
Member

Building on top of #1516

@cloudbees-pull-request-builder

RxJava-pull-requests #1456 ABORTED

@benjchristensen
Copy link
Member Author

I can not yet replicate the hang that's happening on the builds.

It has happened around this area twice:

@cloudbees-pull-request-builder

RxJava-pull-requests #1457 SUCCESS
This pull request looks good

@benjchristensen
Copy link
Member Author

Forcing the build again shows that this change is successful and that unfortunately it is indeed a non-deterministic hang somewhere.

@headinthebox
Copy link
Contributor

Amb (http://www-formal.stanford.edu/jmc/basis1/node7.html#SECTION00025000000000000000) with back pressure is intrinsically hard. If you would do it on iterable you'd need to add a thread.

Glancing at the code, I would request just a single item from each source initially.

if (other != notThis) {
other.unsubscribe();
}
ambSubscribers.clear();
Copy link
Member

Choose a reason for hiding this comment

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

ambSubscribers.clear(); should be out of the loop.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ha! Yes it should :-)

@benjchristensen
Copy link
Member Author

@headinthebox I don't understand the complexity of backpressure on this. It is pretty straight forward to implement here. Whatever the child requests, we propagate to each of the parent Observables and whichever one emits first wins and continues in the "reactive pull" relationship with the child. All the others are unsubscribed and emissions ignored. This means the request(n) count has a 1:1 relationship with whichever the winner is. What am I missing?

@benjchristensen
Copy link
Member Author

@zsxwing can you please review the various changes I've made to prevent race conditions and memory leaks?

@cloudbees-pull-request-builder

RxJava-pull-requests #1459 FAILURE
Looks like there's a problem with this pull request

@benjchristensen
Copy link
Member Author

Ha ... I accidentally didn't commit the chunk of the file including the imports ... re-committing :-)

@cloudbees-pull-request-builder

RxJava-pull-requests #1460 SUCCESS
This pull request looks good

return true;
} else {
// we lost so unsubscribe ... and force cleanup again due to possible race conditions
unsubscribe();
Copy link
Member

Choose a reason for hiding this comment

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

unsubscribe(); is redundant because unsubscribeLosers will call it. LGTM if removing this line.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

zsxwing and others added 2 commits July 30, 2014 09:29
@benjchristensen
Copy link
Member Author

Rebased to collapse my 3 commits. Forced commit. Merging.

Thanks @zsxwing for the reviews and your initial work on this.

benjchristensen added a commit that referenced this pull request Jul 30, 2014
@benjchristensen benjchristensen merged commit 14a41f8 into ReactiveX:master Jul 30, 2014
@benjchristensen benjchristensen deleted the issue-1516 branch July 30, 2014 16:31
@cloudbees-pull-request-builder

RxJava-pull-requests #1461 ABORTED

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.

4 participants