Skip to content

Commit

Permalink
Clarified the expected behaviour for triggerRequest
Browse files Browse the repository at this point in the history
This addresses some of the problem raised in reactive-streams#280.
  • Loading branch information
jroper committed Nov 19, 2018
1 parent 9464664 commit abfbf98
Showing 1 changed file with 16 additions and 1 deletion.
Original file line number Diff line number Diff line change
Expand Up @@ -789,8 +789,23 @@ public interface SubscriberProbe<T> {
* make implement these calls.
*/
public interface SubscriberPuppet {

/**
* Trigger {@code request(elements)} on your {@link Subscriber}
* Ensure that at least {@code elements} are eventually requested by your {@link Subscriber}, if it hasn't already
* requested that many elements.
* <p>
* This does not necessarily have to correlate 1:1 with a {@code Subscription.request(elements)} call, but the sum
* of the elements requested by your {@code Subscriber} must eventually be at least the the sum of the elements
* triggered to be requested by all the invocations of this method.
* <p>
* Additionally, subscribers are permitted to delay requesting elements until previous requests for elements have
* been fulfilled. For example, a subscriber that only requests one element at a time may fulfill the request made
* by this method by requesting one element {@code elements} times, waiting for each element to arrive before the
* next request is made.
* <p>
* Before sending any element to the subscriber, the TCK must wait for the subscriber to request that element, and
* must be prepared for the subscriber to only request one element at a time, it is not enough for the TCK to
* simply invoke this method before sending elements.
*/
void triggerRequest(long elements);

Expand Down

0 comments on commit abfbf98

Please sign in to comment.