OnSubscribeFromIterable - add request overflow check

[davidmoten]

A subscriber like so provokes a hang from OnSubscribeFromIterable due to overflow to negative of requested field:

    @Override
    public void onStart() {
        request(2);
    }

    @Override
    public void onNext(Integer t) {
        request(Long.MAX_VALUE-1);
    }

I've moved the getAndAddRequest method that does the overflow check to a new rx.internal.operators.Util class that is also now used by the request overflow check in OperatorMerge.

Of course there are plenty more of these to be done. I propose to do them bit by bit.

[davidmoten]

REQUESTED get's reduced as well in this OnSubscribe. I'll ponder this and report what effects will be. Might make another change.

[akarnokd]

I think BackpressureUtils would be a better name and an AtomicLong overload would be great.

[davidmoten]

Righto
On 29 Jan 2015 20:02, "David Karnok" [email protected] wrote:

I think BackpressureUtils would be a better name and an AtomicLong
overload would be great.

—
Reply to this email directly or view it on GitHub
#2559 (comment).

[davidmoten]

oops fixing the javadoc

[davidmoten]

Changes made as requested by @akarnokd. The bit I was pondering was what behaviour should be expected of an Observable when additive requests reach Long.MAX_VALUE. I came up with a policy that I added to the javadoc of Subscriber.request and Producer.request:

Requests are additive but if a sequence of requests totals more than Long.MAX_VALUE then Long.MAX_VALUE requests will be actioned and the extras may be ignored. Arriving at Long.MAX_VALUE by addition of requests cannot be assumed to disable backpressure. For example, the code below may result in Long.MAX_VALUE requests being actioned only.

request(100);
request(Long.MAX_VALUE-1);

[akarnokd]

Here is an extra * in the javadoc.

[davidmoten]

fixed javadoc typo, squashed commits

[akarnokd]

Good job! Merging.