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
Multi discrepancies #2413
Multi discrepancies #2413
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -39,7 +39,7 @@ public void subscribe(Flow.Subscriber<? super T> subscriber) { | |
} | ||
|
||
static final class ConcatArraySubscriber<T> extends SubscriptionArbiter | ||
implements Flow.Subscriber<T> { | ||
implements Flow.Subscriber<T> { | ||
|
||
private final Flow.Subscriber<? super T> downstream; | ||
|
||
|
@@ -98,6 +98,7 @@ public void nextSource() { | |
@Override | ||
public void request(long n) { | ||
if (n <= 0) { | ||
cancel(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is not sufficient for the problem that has been discovered. We'll have to address it better. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @olotenko To be clear, your point is that the sequence There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, you can view this as the best effort so far. But like I mentioned offline, there is another issue that needs addressing, so we may just as well postpone touching this class. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see, sounds like for a future PR. |
||
downstream.onError(new IllegalArgumentException("Rule §3.9 violated: non-positive requests are forbidden")); | ||
} else { | ||
super.request(n); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure why you added the masking of the value.
getAndUpdate
returns the value that existed before - so comparing to justREQUEST_ARRIVED
in the POC was intentional.a. in the case that we support masking makes no difference.
b. if the method is abused, and does get called more than once, the POC would still deliver only one value, and masking will deliver more than one value, and break the spec by delivering
onNext
afteronComplete
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that the masking in line 89 is redundant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aha I see, but it makes sense in the other complete() right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, in the other
complete
it reflects the logic of the POC correctly: basically, in thatcomplete
it is "if value has not arrived yet" (was worded with different conditions with OR).But in this
complete
the logic must be "if request has been seen, but the value still not seen" - only in that case we are allowed to deliver the signals to downstream.