Skip to content

Commit 1710ce8

Browse files
2.x Design: Creation/Destruction
How to create and destroy streams. The wording of this can become much better once agreement occurs in https://github.com/ReactiveX/RxJava/pull/3348/files The intent of this is: 1) Specify how to create streams (Observable/Flowable) of the various flavors, and account for flow control. 2) Evolve towards what the creation/generation APIs are 3) Specify that it is not the responsibility of the final Subscriber to call unsubscribe/cancel upstream
1 parent db04cfa commit 1710ce8

File tree

1 file changed

+31
-0
lines changed

1 file changed

+31
-0
lines changed

DESIGN.md

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -74,4 +74,35 @@ It is "hot" because consumers subscribing to it does not cause side-effects, or
7474

7575
A type representing work that can be cancelled or disposed.
7676

77+
### Behavior
78+
79+
##### Creation
80+
81+
Creation of a stream falls into the following use cases, all of which should be catered to in API design.
82+
83+
- async, hot, push (ie. system or user events)
84+
- async, cold, push (ie. events resulting from remote system via network connection)
85+
- sync, cold, pull (ie. iterable, file, range)
86+
- async, cold, pull (ie. RPC/REST network call, cross-thread queue draining)
87+
88+
Unknown:
89+
90+
- hot, pull (what is an example of this?)
91+
92+
Flow control support:
93+
94+
- If `request(n)` behavior is supported in the stream implementation, then:
95+
- pull-based creation must support `request(n)` semantics
96+
- push-based creation must provide a default *onBackpressure* strategy
97+
- If `request(n)` behavior is not supported in the stream implementation, then:
98+
- push-based creation can push without consideration of a backpressure strategy
99+
- pull-based creation should be discouraged
100+
101+
##### Destruction
102+
103+
A producer can terminate a stream by emitting `onComplete` or `onError`. A consumer can terminate a stream by calling `cancel`.
104+
105+
Any resource cleanup of the source or operators must account for any of these three termination events. In other words, if an operator needs cleanup, then it should register the cleanup callback with `cancel`, `onError` and `onComplete`.
106+
107+
The final `subscribe` will *not* invoke `cancel` after receiving an `onComplete` or `onError`.
77108

0 commit comments

Comments
 (0)