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

uli

10/18/2017, 4:19 PM
like this in the example above:
Copy code
counter.send(GetCounter(response))
    println("Counter = ${response.await()}")
    counter.close() // shutdown the actor
}
d

dave08

10/18/2017, 4:24 PM
@uli That's a good observation! So I should just go with the Channel and not the lock() solution?
u

uli

10/18/2017, 4:28 PM
To me, that's exactly what channels are for. It's the higher level abstration and less error prone
d

dave08

10/18/2017, 4:32 PM
Ok thanks, I'll try 🙂
u

uli

10/18/2017, 4:33 PM
Please let us know if this solved your problem
Good luck
d

dave08

10/19/2017, 9:18 AM
@uli I'd have to do this for each step in my pipeline... I have the main channel starting the sync, and during the sync process I have another channel sending actions to handlers. For both of them I need to await a CompletableDeferred, otherwise my IntentService process will finish while the handler coroutines in CommonPool will keep on running?
By the way, thanks for all the help, everybody's so friendly in this slack! 😃
u

uli

10/19/2017, 9:22 AM
@dave08 Thanks for your update.
Just trying to give back. That's how I was treated here.
You use the channel at the beginning of the pipline to limit the number of jobs to 1. Later in the fanout, you can probably skip the channel thingy and rely on async(SomeMultiThreaddedContext), await
d

dave08

10/19/2017, 9:45 AM
For limiting I used CONFLATED, so I should get the latest sync request
u

uhe

10/19/2017, 9:46 AM
Btw: I thought about replacing EventBus with Coroutines, too. However, I came to the conclusion that in many cases it doesn't make a whole lot of sense and even complicates the programming model. Think sticky events and such. So for now I'd use both in conjunction.
That said, if anyone would come up with a proper coroutine-based replacement, I would definitely evaluate that 😄
d

dave08

10/19/2017, 9:47 AM
@uhe In my case, the event bus really complicates things, since I really need a pipeline with an expected flow
u

uli

10/19/2017, 9:47 AM
"Later in the fanout"-> "Further down in the fan out"
d

dave08

10/19/2017, 9:48 AM
I even wanted to replace with rxjava until I found coroutines MUCH cleaner
u

uhe

10/19/2017, 9:48 AM
@dave08 ah, ok. fair enough. depends on the domain, I guess.
d

dave08

10/19/2017, 9:50 AM
@uli I have a varying number/types of actions (like sealed class/request data class) coming from api -- I think that's really Channel/Pipeline-ish?
And I have so far three "nested" chain levels..
SyncRequest -> ActionRequest -> ActionStepRequest
u

uli

10/19/2017, 12:38 PM
Agreed, channels will probably work. Just wondering, if you can not just write the pipeline sequentially to reduce complexity. It probably depends on what level of concurrency you want to reach.
d

dave08

10/19/2017, 12:39 PM
@uli I'm trying that now, but it has a lot of class dependencies...
I built it for eventBus
I wonder if a
BroadcastChannel
in a
companion object
to send/recieve results would be enough
At the beginning of the sync I can open it
during the sync it sends sync progress from all sync components
at the end it is closed
u

uli

10/19/2017, 12:42 PM
I guess it depends on your details. Go for it
d

dave08

10/19/2017, 12:42 PM
When I try starting a new sync, I should check it's state...
But is it thread safe?
4 Views