-
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
Interval #228
Interval #228
Conversation
adjustable time.
when it comes to intervals that are too small to keep up with?
RxJava-pull-requests #83 FAILURE |
RxJava-pull-requests #84 SUCCESS |
Let's consider adding new method to the schedulePeriodically(Action0 action, long initialDelay, long period, TimeUnit unit) It would allow to leverage |
I agree, |
I'll have a look at it. |
Maybe we should also combine all the longs and units into a Timespan class? - It doesn't feel right to always have them as separate parameters. |
…eactiveX#228, needs some testing next...
Anyone know why .Net wouldn't have a If we were to add that it would only really work with This suggests to me that it isn't the right solution to add another interface method as it seems very tied to a particular implementation. Can't this be achieved with recursive schedulers which now work after the changes you did in #229? |
I'm curious about this:
It seems that this operator needs to be async and must default to using something like Documentation at MSDN (http://msdn.microsoft.com/en-us/library/hh228911(v=vs.103).aspx) suggests that this defaults to using a thread-pool scheduler:
Perhaps What happens in .Net if someone tries to use |
If we're going to consider doing this then we should do it as part of #235 before I release another version since this would change the Java itself always keeps the 2 separate though so perhaps the idiomatic thing to do in Java is to keep them separate? I don't have a strong opinion on this one but the decision made now will last a very long time. |
Actually, .Net does have Imho it's useful to avoid recursive scheduling where the schedulers support this directly, as well as to do the slightly messy recursive scheduling ourselves for other types of schedulers, so that the user doesn't have to. |
Ah interesting, thanks for educating me on that. |
This doesn't look like it's been integrated into Observable, but I'm going to merge as it looks useful to get this in ... the TestScheduler especially while Interval continues getting work done. |
Great, thanks (this still needs a bit of work if/when we do periodic scheduling). |
Are you okay with me releasing current code on the master branch and then the rest of Is there anything else about master branch as it stands that should be changed before I release? I'd like to do so today. |
That's alright with me. |
@benjchristensen, now the In Rx.Net, the following codes var o = Observable.Interval(TimeSpan.FromMilliseconds(100), Scheduler.CurrentThread);
o.Take(5).Subscribe(
x => Console.WriteLine(x)
);
o.Take(4).Subscribe(
x => Console.WriteLine(x)
);
Console.ReadLine(); output
In RxJava, the following codes Observable<Long> o = Observable.interval(100, TimeUnit.MILLISECONDS,
Schedulers.currentThread());
o.take(5).subscribe(new Action1<Long>() {
@Override
public void call(Long t1) {
System.out.println(t1);
}
});
o.take(4).subscribe(new Action1<Long>() {
@Override
public void call(Long t1) {
System.out.println(t1);
}
}); output
and the current thread is blocked at the first Is it OK, or the |
…eactiveX#228, needs some testing next...
I have attempted to implement the "Interval" operator (#55) here. As far as I can see, it seems to work. This is based on the quite fresh work on schedulers.
It doesn't work with the
currentThread
ornewThread
schedulers, I guess due to the simpleSleepingAction
. It does work with aScheduledExecutorService
, though.For testing this conveniently, I also wrote a test scheduler with adjustable time.
Looking forward to any review comments.