Fairness of range() and repeat()

```
The current implementation of repeatedly emitting values in the operators
range() and repeat() are unfair: they are monopolizing the underlying
scheduler. This is acceptable (and preferred from performance perspective) on
schedulers such as the default and new-thread. The current thread and EDT
schedulers however would suffer in such cases.

The resolution of course is to grain the value emission by re-scheduling the
body. The question is, how to present these alternatives to the user?

- separate names (rangeFair(), repeatFair())
- require a SchedulerLongRunning indicator interface to indicate that it is
able to run such operations above without problems?
- enhance the scheduler interface to present some capabilities and the normal
implementations just switch based on it.

```

Original issue reported on code.google.com by `akarn...@gmail.com` on 3 Apr 2012 at 3:20