A modern programming language that makes developers happier.

kotlinlang

like this in the example above:
```counter.send(GetCounter(response))
    println("Counter = ${response.await()}")
    counter.close() // shutdown the actor
}```

<@U3ZPQ4QR4> That's a good observation! So I should just go with the Channel and not the lock() solution?

To me, that's exactly what channels are for. It's the higher level abstration and less error prone

Ok thanks, I'll try :slightly_smiling_face:

Please let us know if this solved your problem

<@U3ZPQ4QR4> 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! :smiley:

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

For limiting I used CONFLATED, so I should get the latest sync request

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 :smile:

<@U0QKGKMKN> In my case, the event bus really complicates things, since I really need a pipeline with an expected flow

"Later in the fanout"-&gt; "Further down in the fan out"

I even wanted to replace with rxjava until I found coroutines MUCH cleaner

<@U6P03BM0W> ah, ok. fair enough. depends on the domain, I guess.

<@U3ZPQ4QR4> 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 -&gt; ActionRequest -&gt; ActionStepRequest

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.

<@U3ZPQ4QR4> I'm trying that now, but it has a lot of class dependencies...

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

I guess it depends on your details. Go for it

When I try starting a new sync, I should check it's state...