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

=tck #362 signal onComplete in 201 blackbox verification #372

Merged
merged 2 commits into from
Jun 16, 2017

Conversation

ktoso
Copy link
Contributor

@ktoso ktoso commented May 29, 2017

Follow up to things found in #362

@@ -96,11 +96,16 @@ public void required_spec201_blackbox_mustSignalDemandViaSubscriptionRequest() t
@Override
public void run(BlackboxTestStage stage) throws InterruptedException {
triggerRequest(stage.subProxy().sub());
final long n = stage.expectRequest();// assuming subscriber wants to consume elements...
final long requested = stage.expectRequest();// assuming subscriber wants to consume elements...
final long signalsToEmit = Math.min(requested, 512); // protecting against Subscriber which sends ridiculous large demand
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Or could be TestEnvironment.TEST_BUFFER_SIZE, anything less than huge numbers is fine here though IMO


// should cope with up to requested number of elements
for (int i = 0; i < n; i++)
for (int i = 0; i < signalsToEmit; i++)
Copy link
Contributor

Choose a reason for hiding this comment

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

This could also check if the Subscriber signalled cancel and not loop unnecessarily.


// we complete after `signalsToEmit` (which can be less than `requested`),
// which is legal under https://github.com/reactive-streams/reactive-streams-jvm#1.2
stage.sendCompletion();
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we sendCompletion() even if cancelled?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why not? Cancellation is allowed to be "racy"

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess the "polite" implementation would check if it is not cancelled before issuing the completion. (so that the implementation does not rely on onComplete if cancelled)

@viktorklang viktorklang merged commit 64ab75f into reactive-streams:master Jun 16, 2017
@viktorklang viktorklang added this to the 1.0.1 milestone Jun 16, 2017
@ktoso ktoso deleted the wip-complete-in-201 branch June 26, 2017 18:32
@ktoso ktoso mentioned this pull request Jun 26, 2017
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants