-
Notifications
You must be signed in to change notification settings - Fork 7.6k
ScheduledObserver Ordering #234
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
Conversation
RxJava-pull-requests #90 FAILURE |
} | ||
|
||
if (count > 0) { | ||
scheduler.schedule(this); |
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 might grow the stack size, should be reimplemented.
RxJava-pull-requests #91 FAILURE |
RxJava-pull-requests #92 ABORTED |
RxJava-pull-requests #93 SUCCESS |
I'm not sure if this is a really working solution as well, looks too simple. |
Thanks, I'd appreciate that as I haven't had time to think through those. |
Okay, this seems to be working. Assuming that underlying observable implemented correctly, this means that OnNext, OnCompleted and OnError events will be called sequentially. The solution itself is inspired by the way a CurrentThreadScheduler works except that it relies on concurrent primitives instead of ThreadLocal. I can see 4 cases:
@benjchristensen what do you think? |
|
||
} | ||
|
||
int count = counter.decrementAndGet(); |
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.
I think that as long as nothing makes any calls to the underlying observer after this line it should be ok.
…or_rate_limiter Non-blocking API for RateLimiter
Fixing issue #233.
Blocking solution for now, thinking about non-blocking alternatives.