From 328c60f5d4c408d4ebc30d00d9a394d9fbba7e23 Mon Sep 17 00:00:00 2001 From: Viktor Klang Date: Sun, 5 Mar 2017 21:51:52 +0100 Subject: [PATCH 1/2] Minor rewording of 2.6 to make it easier to understand. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index b22c0da4..5162b0db 100644 --- a/README.md +++ b/README.md @@ -139,7 +139,7 @@ public interface Subscriber { | [:bulb:](#2.4 "2.4 explained") | *The intent of this rule is to make sure that Subscribers respect a Publisher’s [terminal state](#term_terminal-state) signals. A Subscription is simply not valid anymore after an onComplete or onError signal has been received.* | | 5 | A `Subscriber` MUST call `Subscription.cancel()` on the given `Subscription` after an `onSubscribe` signal if it already has an active `Subscription`. | | [:bulb:](#2.5 "2.5 explained") | *The intent of this rule is to prevent that two, or more, separate Publishers from thinking that they can interact with the same Subscriber. Enforcing this rule means that resource leaks are prevented since extra Subscriptions will be cancelled.* | -| 6 | A `Subscriber` MUST call `Subscription.cancel()` if it is no longer valid to the `Publisher` without the `Publisher` having signaled `onError` or `onComplete`. | +| 6 | A `Subscriber` MUST call `Subscription.cancel()` if it is no longer valid to its `Publisher`, without the `Publisher` having signaled `onError` or `onComplete`. | | [:bulb:](#2.6 "2.6 explained") | *The intent of this rule is to establish that Subscribers cannot just throw Subscriptions away when they are no longer needed, they have to call `cancel` so that resources held by that Subscription can be safely, and timely, reclaimed.* | | 7 | A `Subscriber` MUST ensure that all calls on its `Subscription` take place from the same thread or provide for respective external synchronization. | | [:bulb:](#2.7 "2.7 explained") | *The intent of this rule is to establish that external synchronization must be added if a Subscriber will be using a Subscription concurrently by two or more threads.* | From c3f8b64f913909f2ceda791963c47d2fe39d08e2 Mon Sep 17 00:00:00 2001 From: Viktor Klang Date: Mon, 6 Mar 2017 09:54:21 +0100 Subject: [PATCH 2/2] Second attempt at rewording 2.6 --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 5162b0db..44fa0fd7 100644 --- a/README.md +++ b/README.md @@ -139,8 +139,8 @@ public interface Subscriber { | [:bulb:](#2.4 "2.4 explained") | *The intent of this rule is to make sure that Subscribers respect a Publisher’s [terminal state](#term_terminal-state) signals. A Subscription is simply not valid anymore after an onComplete or onError signal has been received.* | | 5 | A `Subscriber` MUST call `Subscription.cancel()` on the given `Subscription` after an `onSubscribe` signal if it already has an active `Subscription`. | | [:bulb:](#2.5 "2.5 explained") | *The intent of this rule is to prevent that two, or more, separate Publishers from thinking that they can interact with the same Subscriber. Enforcing this rule means that resource leaks are prevented since extra Subscriptions will be cancelled.* | -| 6 | A `Subscriber` MUST call `Subscription.cancel()` if it is no longer valid to its `Publisher`, without the `Publisher` having signaled `onError` or `onComplete`. | -| [:bulb:](#2.6 "2.6 explained") | *The intent of this rule is to establish that Subscribers cannot just throw Subscriptions away when they are no longer needed, they have to call `cancel` so that resources held by that Subscription can be safely, and timely, reclaimed.* | +| 6 | A `Subscriber` MUST call `Subscription.cancel()` if the `Subscription` is no longer needed. | +| [:bulb:](#2.6 "2.6 explained") | *The intent of this rule is to establish that Subscribers cannot just throw Subscriptions away when they are no longer needed, they have to call `cancel` so that resources held by that Subscription can be safely, and timely, reclaimed. An example of this would be a Subscriber which is only interested in a specific element, which would then cancel its Subscription to signal its completion to the Publisher.* | | 7 | A `Subscriber` MUST ensure that all calls on its `Subscription` take place from the same thread or provide for respective external synchronization. | | [:bulb:](#2.7 "2.7 explained") | *The intent of this rule is to establish that external synchronization must be added if a Subscriber will be using a Subscription concurrently by two or more threads.* | | 8 | A `Subscriber` MUST be prepared to receive one or more `onNext` signals after having called `Subscription.cancel()` if there are still requested elements pending [see [3.12](#3.12)]. `Subscription.cancel()` does not guarantee to perform the underlying cleaning operations immediately. |