Preserve 'interrupted' state in blocking methods

[CheatEx]

I've noted that BlockingMultiObserver#blockingGet() wraps and re-throws InterruptedException. This makes hard to recover interrupted state of a thread. The general convention is to either throw IE as is or restore the interrupted state so downstream code could handle it too.

RxJava seem to partially follow this convention, see #147 and

RxJava/src/main/java/io/reactivex/rxjava3/internal/util/BlockingHelper.java

Line 45 in b3ad075

Thread.currentThread().interrupt();

But not in the most used public methods.

Did you consider restoring interrupted state in blocking operations designed for external use, specifically in Completable, Single, Maybe, Observable blocking* methods?

[akarnokd]

Did you consider restoring interrupted state

Yes and decided not to in most cases. The trouble is, restoring the interrupted state may lead to further unintended interrupts.

[CheatEx]

further unintended interrupts

Further interrupts are intended. I would even say desired. The point usually is to terminate a thread ASAP.

[akarnokd]

Do you have a specific problem or are you just reciting some external convention without contextual considerations of RxJava?

[CheatEx]

No, I'm only learning and evaluating RxJ.

So I would really appreciate if you share those contextual considerations. Or maybe point out a resource where I can learn more about RxJavas convention for cancelling and shutdown of blocked threads.

[akarnokd]

RxJava is about non-blocking operations and cancellation is just another signal that propagates non-blockingly. However, when dealing with external, blocking APIs, cancellation does trigger thread interruption for the purpose to unblock those specific 3rd party calls. This doesn't automatically imply the next 3rd party call should be interrupted immediately just because it happens to run on the same thread.

Here are some past issues regarding similar situations: https://github.com/ReactiveX/RxJava/issues?q=is%3Aissue+interrupt+is%3Aclosed