Observable.interval(0) locks up browser incorrectly

[jayphelps]

This code:

Observable.interval(0)
  .throttleTime(1000)
  .subscribe(item => console.log(item));

Should not lock up the browser, because using a setInterval(func, 0) won't, as long as the func isn't crazy.

If you change it to Observable.interval(1), it works as expected, so @Blesh thinks it probably is trying to be overly smart and instead do a regular for loop or equivalent blocking operation.

https://jsbin.com/qiperi/edit?js,console,output (example here uses .interval(1) to not lock up your browser immediately, but if you change it to 0 it will lock up)

[jayphelps]

Guessing it has something to do with using AsapScheduler and that scheduler exec immediately if delay is 0.

https://github.com/ReactiveX/RxJS/blob/59a8c186138ddb1b8fcf2a6e1ab80a87812f78a2/src/scheduler/AsapAction.ts#L8

Without knowing enough about why each scheduler exists, it seems to me like .interval() should use a FutureScheduler (that uses FutureAction) but that doesn't exist atm.

[trxcllnt]

@jayphelps Observable.interval defaults to Scheduler.asap, which schedules actions with delay <= 0 using setImmediate (or equivalent for the environment). I understand microtasks do block the event loop. We are in need of a Scheduler.async impl that always returns a FutureAction from Scheduler.prototype.scheduleNow (similar to Scheduler.asap).

[benlesh]

I understand microtasks do block the event loop.

Oh yeah. Derp. If your schedule an infinite loop of micro tasks, everything you schedule has to run before anything else on the event loop. As such it'll block for anything you're not scheduling as a micro task. LOL. Makes total sense.

[benlesh]

This should probably default to a different scheduler. Leaving it as a bug for now.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.