-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
ReplaySubject with time and size bounds #1192
Conversation
RxJava-pull-requests #1104 FAILURE |
RxJava-pull-requests #1105 FAILURE |
Nice, people will be happy to have all the functionality on Should we wait until after #1185 to rebase and merge this? I have not yet reviewed this. |
I'd review and merge this first and go back to #1185 as it surely needs some rebase anyway. |
* The weak reference back to the previous node. If that node is not | ||
* hard-referenced, it will be eventually GCd. | ||
*/ | ||
final WeakReference<Node<T>> previous; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is unnecessary as noone is walking backwards. A singly-linked list is enough.
Closing this as the master merge got messed up. |
RxJava-pull-requests #1126 FAILURE |
I've implemented the bounded
ReplaySubject
variants and removed the oldOperatorReplay.CustomReplaySubject
so the variousObservable.replay()
now use this version.Note that this is based on the current
SubjectSubscriptionManager
and not my manager from PR #1185. I've copied theReplaySubjectConcurrencyTest
to check the concurrency properties.The bounded buffering is implemented via a doubly-linked list where the back reference is a weak reference. This allows keeping a reference to the latest
Node
for each replayState and once a Node is no longer indexed, it will be removed by GC.A concurrency review would be much appreciated.