https://kotlinlang.org logo
#coroutines
Title
# coroutines
u

ursus

07/04/2020, 11:35 AM
did I miss something? are there any gotchas?
e

Erik

07/04/2020, 11:38 AM
Quite a complete summary/dictionary! I'd say that the gotcha is that both require a certain mental model of what's going on. Both can be daunting or very logical, depending on what you like.
👍 2
u

ursus

07/04/2020, 11:39 AM
From what I see the mental model is really the same, with only different names?
e

Erik

07/04/2020, 11:39 AM
For me personally, for example, the Rx stuff looks daunting for newbies, while the coroutine stuff is a bit easier to read and to get started with
It's a matter of style and that's partly subjective
u

ursus

07/04/2020, 11:40 AM
Yea, lets discount that, I already know rx
e

Erik

07/04/2020, 11:40 AM
The 'Structured Concurrency' paradigm is important to keep in mind when working with coroutines
u

ursus

07/04/2020, 11:41 AM
Thats just scoping of asynchrony, disposables/composite disposables do that, no?
e

Erik

07/04/2020, 11:41 AM
And the Job state machine, especially when dealing with exceptions and cancellation, is something that may be difficult
u

ursus

07/04/2020, 11:42 AM
is it the
launch
vs
ąsync
thing?
e

Erik

07/04/2020, 11:42 AM
Amongst others, yes
u

ursus

07/04/2020, 11:43 AM
I'll take a note thanks
e

Erik

07/04/2020, 11:43 AM
The child-parent relationship of jobs
Who cancels who and when
Who handles exceptions
The happy path is easy. Dealing with exceptions is the important work. Also, concurrency isn't free, so cancelling work and making it cancellable is also important. Not different than with Rx, but still the implementation details are an interesting subject
u

ursus

07/04/2020, 11:45 AM
so in general, whether parent should be also canceled, transitively canceling all children?
e

Erik

07/04/2020, 11:45 AM
Yes, that's the default, but you can control that
u

ursus

07/04/2020, 11:46 AM
I see, pretty much same with rx
e

Erik

07/04/2020, 11:46 AM
Also, cooperative cancellation is a topic you should read about: when a job is cancelled it can keep running if it needs
But it should stop working ASAP, but a bad impl would keep running
u

ursus

07/04/2020, 11:47 AM
Sounds the same as wraping a 3rd party api and not using
setCancelable { }
in rx
and blocking code would also not cancel, same
e

Erik

07/04/2020, 11:50 AM
I'd advice you to try and build your next feature using coroutines. Or refactor a simple one. It sounds like you've got this mental model of (a) synchronous streams and concurrency good enough already!
u

ursus

07/04/2020, 11:51 AM
Yea I was wondering if I should do that + adapters back to rx -- while sharing threadpools behind dispaters/schedulers, there shouldnt be much of a overhead, right?
e

Erik

07/04/2020, 11:53 AM
Any coroutine compatible code (e.g. a
suspend fun x()
) can be called from the current thread using
runBlocking { x() }
. That's your adapter, if you want to call these suspending functions and wrap them in Rx constructs
I believe that the Kotlin coroutines lib also provides some adapters, e.g. to convert a
Flow<T>
to
Observable<T>
and vice versa.
u

ursus

07/04/2020, 11:55 AM
yea those exists, I meant runtime overhead with not sharing actual threads
e

Erik

07/04/2020, 11:55 AM
Maybe in a separate dependency, but it probably is a very thin wrapper between the libs
Both RxJava and Kotlin coroutines are optimised quite a bit already. The most overhead would be setting up the thread pools for the first time, probably. Once the schedulers' and dispatchers' underlying thread pools have spun up, they are probably cheap to use
It should be possible to create your own dispatcher from a thread or thread pool, maybe even from an Rx scheduler
I have no experience with this though
That way you could truly share the same threads!
u

ursus

07/04/2020, 12:00 PM
nice, thats what I need
e

Erik

07/04/2020, 12:00 PM
That site is what I use a lot for documentation on coroutines, in general, if you hadn't found it yet!
u

ursus

07/04/2020, 1:45 PM
thanks!
4 Views