https://kotlinlang.org logo
Join Slack
Powered by
did I miss something? are there any gotchas?
# coroutines
u
did I miss something? are there any gotchas?
e
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
From what I see the mental model is really the same, with only different names?
e
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
Yea, lets discount that, I already know rx
e
The 'Structured Concurrency' paradigm is important to keep in mind when working with coroutines
u
Thats just scoping of asynchrony, disposables/composite disposables do that, no?
e
And the Job state machine, especially when dealing with exceptions and cancellation, is something that may be difficult
u
is it the 
launch
vs 
ąsync
thing?
e
Amongst others, yes
u
I'll take a note thanks
e
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
so in general, whether parent should be also canceled, transitively canceling all children?
e
Yes, that's the default, but you can control that
u
I see, pretty much same with rx
e
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
Sounds the same as wraping a 3rd party api and not using 
setCancelable { }
in rx
and blocking code would also not cancel, same
e
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
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
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
yea those exists, I meant runtime overhead with not sharing actual threads
e
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
nice, thats what I need
e
That site is what I use a lot for documentation on coroutines, in general, if you hadn't found it yet!
u
thanks!
5 Views
Open in Slack
PreviousNext
Powered by