You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* A {@code Scheduler} is an object that specifies an API for scheduling
30
-
* units of work with or without delays or periodically.
31
-
* You can get common instances of this class in {@link io.reactivex.schedulers.Schedulers}.
30
+
* units of work provided in the form of {@link Runnable}s to be
31
+
* executed without delay (effectively as soon as possible), after a specified time delay or periodically
32
+
* and represents an abstraction over an asynchronous boundary that ensures
33
+
* these units of work get executed by some underlying task-execution scheme
34
+
* (such as custom Threads, event loop, {@link java.util.concurrent.Executor Executor} or Actor system)
35
+
* with some uniform properties and guarantees regardless of the particular underlying
36
+
* scheme.
37
+
* <p>
38
+
* You can get various standard, RxJava-specific instances of this class via
39
+
* the static methods of the {@link io.reactivex.schedulers.Schedulers} utility class.
40
+
* <p>
41
+
* The so-called {@link Worker}s of a {@code Scheduler} can be created via the {@link #createWorker()} method which allow the scheduling
42
+
* of multiple {@link Runnable} tasks in an isolated manner. {@code Runnable} tasks scheduled on a {@code Worker} are guaranteed to be
43
+
* executed sequentially and in a non-overlapping fashion. Non-delayed {@code Runnable} tasks are guaranteed to execute in a
44
+
* First-In-First-Out order but their execution may be interleaved with delayed tasks.
45
+
* In addition, outstanding or running tasks can be cancelled together via
46
+
* {@link Worker#dispose()} without affecting any other {@code Worker} instances of the same {@code Scheduler}.
47
+
* <p>
48
+
* Implementations of the {@link #scheduleDirect} and {@link Worker#schedule} methods are encouraged to call the {@link io.reactivex.plugins.RxJavaPlugins#onSchedule(Runnable)}
49
+
* method to allow a scheduler hook to manipulate (wrap or replace) the original {@code Runnable} task before it is submitted to the
50
+
* underlying task-execution scheme.
51
+
* <p>
52
+
* The default implementations of the {@code scheduleDirect} methods provided by this abstract class
53
+
* delegate to the respective {@code schedule} methods in the {@link Worker} instance created via {@link #createWorker()}
54
+
* for each individual {@link Runnable} task submitted. Implementors of this class are encouraged to provide
55
+
* a more efficient direct scheduling implementation to avoid the time and memory overhead of creating such {@code Worker}s
56
+
* for every task.
57
+
* This delegation is done via special wrapper instances around the original {@code Runnable} before calling the respective
58
+
* {@code Worker.schedule} method. Note that this can lead to multiple {@code RxJavaPlugins.onSchedule} calls and potentially
59
+
* multiple hooks applied. Therefore, the default implementations of {@code scheduleDirect} (and the {@link Worker#schedulePeriodically(Runnable, long, long, TimeUnit)})
60
+
* wrap the incoming {@code Runnable} into a class that implements the {@link io.reactivex.schedulers.SchedulerRunnableIntrospection}
61
+
* interface which can grant access to the original or hooked {@code Runnable}, thus, a repeated {@code RxJavaPlugins.onSchedule}
62
+
* can detect the earlier hook and not apply a new one over again.
63
+
* <p>
64
+
* The default implementation of {@link #now(TimeUnit)} and {@link Worker#now(TimeUnit)} methods to return current
65
+
* {@link System#currentTimeMillis()} value in the desired time unit. Custom {@code Scheduler} implementations can override this
66
+
* to provide specialized time accounting (such as virtual time to be advanced programmatically).
67
+
* Note that operators requiring a {@code Scheduler} may rely on either of the {@code now()} calls provided by
68
+
* {@code Scheduler} or {@code Worker} respectively, therefore, it is recommended they represent a logically
69
+
* consistent source of the current time.
70
+
* <p>
71
+
* The default implementation of the {@link Worker#schedulePeriodically(Runnable, long, long, TimeUnit)} method uses
72
+
* the {@link Worker#schedule(Runnable, long, TimeUnit)} for scheduling the {@code Runnable} task periodically.
73
+
* The algorithm calculates the next absolute time when the task should run again and schedules this execution
74
+
* based on the relative time between it and {@link Worker#now(TimeUnit)}. However, drifts or changes in the
75
+
* system clock could affect this calculation either by scheduling subsequent runs too frequently or too far apart.
76
+
* Therefore, the default implementation uses the {@link #clockDriftTolerance()} value (set via
77
+
* {@code rx2.scheduler.drift-tolerance} in minutes) to detect a drift in {@link Worker#now(TimeUnit)} and
78
+
* re-adjust the absolute/relative time calculation accordingly.
79
+
* <p>
80
+
* The default implementations of {@link #start()} and {@link #shutdown()} do nothing and should be overridden if the
81
+
* underlying task-execution scheme supports stopping and restarting itself.
82
+
* <p>
83
+
* If the {@code Scheduler} is shut down or a {@code Worker} is disposed, the {@code schedule} methods
84
+
* should return the {@link io.reactivex.disposables.Disposables#disposed()} singleton instance indicating the shut down/disposed
85
+
* state to the caller. Since the shutdown or dispose can happen from any thread, the {@code schedule} implementations
86
+
* should make best effort to cancel tasks immediately after those tasks have been submitted to the
87
+
* underlying task-execution scheme if the shutdown/dispose was detected after this submission.
88
+
* <p>
89
+
* All methods on the {@code Scheduler} and {@code Worker} classes should be thread safe.
32
90
*/
33
91
publicabstractclassScheduler {
34
92
/**
35
93
* The tolerance for a clock drift in nanoseconds where the periodic scheduler will rebase.
36
94
* <p>
37
-
* The associated system parameter, {@code rx.scheduler.drift-tolerance}, expects its value in minutes.
95
+
* The associated system parameter, {@code rx2.scheduler.drift-tolerance}, expects its value in minutes.
38
96
*/
39
97
staticfinallongCLOCK_DRIFT_TOLERANCE_NANOSECONDS;
40
98
static {
@@ -44,7 +102,7 @@ public abstract class Scheduler {
44
102
45
103
/**
46
104
* Returns the clock drift tolerance in nanoseconds.
47
-
* <p>Related system property: {@code rx2.scheduler.drift-tolerance} in minutes
105
+
* <p>Related system property: {@code rx2.scheduler.drift-tolerance} in minutes.
48
106
* @return the tolerance in nanoseconds
49
107
* @since 2.0
50
108
*/
@@ -54,11 +112,13 @@ public static long clockDriftTolerance() {
54
112
55
113
56
114
/**
57
-
* Retrieves or creates a new {@link Scheduler.Worker} that represents serial execution of actions.
115
+
* Retrieves or creates a new {@link Scheduler.Worker} that represents sequential execution of actions.
58
116
* <p>
59
-
* When work is completed it should be unsubscribed using {@link Scheduler.Worker#dispose()}.
117
+
* When work is completed, the {@code Worker} instance should be released
118
+
* by calling {@link Scheduler.Worker#dispose()} to avoid potential resource leaks in the
119
+
* underlying task-execution scheme.
60
120
* <p>
61
-
* Work on a {@link Scheduler.Worker} is guaranteed to be sequential.
121
+
* Work on a {@link Scheduler.Worker} is guaranteed to be sequential and non-overlapping.
62
122
*
63
123
* @return a Worker representing a serial queue of actions to be executed
64
124
*/
@@ -78,29 +138,37 @@ public long now(@NonNull TimeUnit unit) {
78
138
/**
79
139
* Allows the Scheduler instance to start threads
80
140
* and accept tasks on them.
81
-
* <p>Implementations should make sure the call is idempotent and thread-safe.
141
+
* <p>
142
+
* Implementations should make sure the call is idempotent, thread-safe and
143
+
* should not throw any {@code RuntimeException} if it doesn't support this
144
+
* functionality.
145
+
*
82
146
* @since 2.0
83
147
*/
84
148
publicvoidstart() {
85
149
86
150
}
87
151
88
152
/**
89
-
* Instructs the Scheduler instance to stop threads
90
-
* and stop accepting tasks on any outstanding Workers.
91
-
* <p>Implementations should make sure the call is idempotent and thread-safe.
153
+
* Instructs the Scheduler instance to stop threads,
154
+
* stop accepting tasks on any outstanding {@link Worker} instances
155
+
* and clean up any associated resources with this Scheduler.
156
+
* <p>
157
+
* Implementations should make sure the call is idempotent, thread-safe and
158
+
* should not throw any {@code RuntimeException} if it doesn't support this
159
+
* functionality.
92
160
* @since 2.0
93
161
*/
94
162
publicvoidshutdown() {
95
163
96
164
}
97
165
98
166
/**
99
-
* Schedules the given task on this scheduler non-delayed execution.
167
+
* Schedules the given task on this Scheduler without any time delay.
100
168
*
101
169
* <p>
102
170
* This method is safe to be called from multiple threads but there are no
103
-
* ordering guarantees between tasks.
171
+
* ordering or non-overlapping guarantees between tasks.
104
172
*
105
173
* @param run the task to execute
106
174
*
@@ -113,7 +181,7 @@ public Disposable scheduleDirect(@NonNull Runnable run) {
113
181
}
114
182
115
183
/**
116
-
* Schedules the execution of the given task with the given delay amount.
184
+
* Schedules the execution of the given task with the given time delay.
117
185
*
118
186
* <p>
119
187
* This method is safe to be called from multiple threads but there are no
@@ -139,15 +207,16 @@ public Disposable scheduleDirect(@NonNull Runnable run, long delay, @NonNull Tim
139
207
}
140
208
141
209
/**
142
-
* Schedules a periodic execution of the given task with the given initial delay and period.
210
+
* Schedules a periodic execution of the given task with the given initial time delay and repeat period.
143
211
*
144
212
* <p>
145
213
* This method is safe to be called from multiple threads but there are no
146
214
* ordering guarantees between tasks.
147
215
*
148
216
* <p>
149
-
* The periodic execution is at a fixed rate, that is, the first execution will be after the initial
150
-
* delay, the second after initialDelay + period, the third after initialDelay + 2 * period, and so on.
217
+
* The periodic execution is at a fixed rate, that is, the first execution will be after the
218
+
* {@code initialDelay}, the second after {@code initialDelay + period}, the third after
0 commit comments