09/11/2017, 7:31 AM
@jw A coroutines threading model is different from Rx threading model. In Rx the thread your code runs in is implicitly controlled by various onXXX operators up/down the stream, while in coroutines the thread (context) is explicitly specified for each coroutine. The only exception is
context, which leaves the thread “unspecified”.


09/11/2017, 1:12 PM
The on* operators have no effect on threading and are much more like Unconfined where they run on whatever thread is emitting (which is true of nearly all operators). Did you mean observeOn/subscribeOn?
But anyway I have the current context (via
) and the target context so I figured that I could replicate observeOn by having the current context loop and then send values across a channel onto a loop in the target context.


09/11/2017, 1:50 PM
I meant observeOn/subscribeOn, thanks
context gives you similar, but not really the same behavior as Rx. Consider the following pipeline:
produce(Context1) { ... }.map(Unconfined) { ... }.consume(Context2) { ... }
So, you have a producer running in one thread and a consumer in another thread, with unconfined transformer in between. What thread the transformer runs in? The answer — it depends. With standard channel implementations from
the transformer sometimes runs in one thread, sometimes in the other. If the producer is faster than the consumer, then the producer is resuming suspended transformer coroutine, thus the transformer runs in the first thread. However, if the consumer is faster than the producer, then the consumer is resuming suspended transformer coroutine and thus transformer runs in the second thread. In order to imitate Rx behavior you either have to explicitly inherit producer’s context or exercise special care about the kinds of channels you are using in between the coroutines.
👍 2