Using RxGRDB with TestScheduler about rxgrdb HOT 5 CLOSED

Hello @davidkraus

I'm not familiar enough with schedulers to answer your question yet. We're both RxSwift schedulers newbies :-)

I know that SerialDispatchQueueScheduler provides the kind of guarantees that RxGRDB needs. But a more general protocol may still honor the very strict scheduling requirements of SQLite. I'll need to have a look.

from rxgrdb.

OK @davidkraus, let's investigate what those schedulers are 🤘

The Schedulers documentation is useful, but also not very clear. There are sentences like the following, which is impossible to understand:

In case the scheduler is concurrent, Rx's observeOn and subscribeOn operators will make sure everything works perfectly.

Thank you, but I'd like to know what this "perfection" is about ;-) The ReactiveX page on Schedulers does not bring more information.

Either you're not supposed to know what a scheduler really is, or schedulers are very hard to describe. Maybe there is a reference somewhere, which aims at helping the various ReactiveX implementations being compatible, but I could not find it.

Fortunately, there are hints in RxSwift doc that the fundamental job of RxSwift schedulers is to execute single-threaded "actions", one at a time, and that actions can not be reentrantly nested (one action can not be part of another one):

If you use some scheduler that Rx can prove is serial, it will be able to perform additional optimizations.

If some parent frame on the call stack is already running CurrentThreadScheduler.instance.schedule(state) { }, the scheduled action will be enqueued and executed when the currently running action and all previously enqueued actions have finished executing.

I don't know if this guarantee is particular to RxSwift, an implementation detail, or if this is true for all ReactiveX schedulers in general.

Now let's look at the two available Scheduler protocols: ImmediateSchedulerType, and SchedulerType.

They can schedule actions "immediately", "relatively", "periodically", or "recursively". My interpretations:

• "immediately" has an action enqueued for being executed as soon as possible.
• "relatively" has an action enqueued for being executed after a delay.
• "periodically" deals with timers.
• "recursively" deals with tail recursion.

There's still nothing that defines what a scheduler is, but there is nothing that invalidates the hypothesis that "schedulers execute single-threaded actions, one at a time, and avoid reentrancy".

I think we'll need @kzaher to know, for good, what is the scheduler contract.

But I have enough information now for answering your question 😄

Since RxGRDB, as far as I know, just needs serial execution (the guarantee that no two scheduled actions overlap), I can replace SerialDispatchQueueScheduler with ImmediateSchedulerType in the RxGRDB APIs.

A new release will ship shortly. And thanks for your question!

from rxgrdb.

Done, you can use any scheduler you want with RxGRDB v0.9.0.

from rxgrdb.

Wow thanks, you are fast ;).
I just tested our code with v0.9.0 and it works now 🎉.

Ok so the Scheduler thing: As far as i understand it the Scheduler does not magically introduce any kind of concurrency - And i think they can't because this would interfere with the Observable contract (onNext sequentially and on the same thread). If you want to parallelise your code you have to use a combination of flatMap and observeOn (see https://tomstechnicalblog.blogspot.de/2015/11/rxjava-achieving-parallelization.html).

from rxgrdb.

David, you're totally right! The contract I have been looking for in schedulers was actually defined on observables themselves :-)

from rxgrdb.