-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Abstraction for Clock with DI via RxJavaPlugins #3295
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Do we have a desktop Java version of this |
We have System.nanoTime at both - Android and JRE. |
|
Weaker guarantees than what? There are no other nanosecond precision counters in Java. nanoTime has better guarantees than others just because it is nano. It is just slower sometimes. |
Nope :( Some OSses give such APIs but it'll require JNI call, though one of the ideas of
For example, in multi-CPU systems |
To note, I think the spirit of this has been addressed in Java 8's Clock. If there is a need to support < 8, the Java 8 Date/Time refactor has been externally back ported via the ThreeTen project, which exposes a similar clock abstraction. cc @jodastephen. If there is a strong need to limit the dependencies, maybe it's still worth modeling after these abstractions. |
Closing for now, #3467 looks good so far. |
Intro: in RxJava (for the Operators) time is related to a Scheduler that runs the code, and this is awesome (
Schedulers.test()
proves that).But, at the moment RxJava's Schedulers use
System.currentTimeMillis()
as the source of the time to make some time-relative things work:delay()
,window()
,schedule()
,schedulePeriodically()
,Schedulers.test()
and so on.The problem with
System.currentTimeMillis()
is that it represents "wall clock" which can be changed by:Such changes of wall clock may break the business logic of the applications (think about banking, security, apps and systems) and even crash them or create dead/live locks.
Proposal: Add
Clock
abstraction which will useSystem.currentTimeMillis()
by default (no breaking changes) and ability for the users to inject their own implementation viaRxJavaPlugins
.In Android we can use
this via RxAndroid as a default option for RxJava on Android, or it's possible to do this via reflection directly in RxJava (though I am not a fan of reflection in RxJava).
SystemClock.elapsedRealtime()
as the source of linear, monotonic time in milliseconds. I guess, we will even be able to shipSee also #2943.
I can work on PR for this both for RxJava and RxAndroid if RxJava team will agree with this proposal.
CC all who interested in this, what is your opinion?
The text was updated successfully, but these errors were encountered: