<@U0ANSGGVC> I've written some kotlin-ish pseudo c...

# coroutines

[groostav]

@kirillrakhman I've written some kotlin-ish pseudo code here, I'd really appreciate you taking a look
https://gist.github.com/Groostav/7e89dde503909a13d9ac21cd3c0f4fa2

[kirillrakhman]

what is it exactly I should look for?

[groostav]

specifically im only using CompletableFutures and olde-school java in the dispatching component

[groostav]

Is that as good as it gets?

[kirillrakhman]

you should take a look at https://github.com/Kotlin/kotlinx.coroutines/tree/master/kotlinx-coroutines-jdk8

[groostav]

also of course, as per the discussion we just had, launch(CommonPool) { while(true) { ... is really stupid, and I should be using launch(cachedThreadPool.asDispatcher()

[kirillrakhman]

there is a coroutine builder future for creating a coroutine that returns a CompletableFuture

[groostav]

I think im OK to expose a suspend fun read(): Message instead of a fun read(): CompletableFuture<Message> there

[groostav]

although I do like the idea of object-boundaries being java compatable where its not too intrusive

[kirillrakhman]

also, you're doing a lot of blocking and synchronizing inside coroutines which seems to go against its philosophy. maybe you should take a look at channels and other coroutines classes inside kotlinx.coroutines

[kirillrakhman]

https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md#channels

[groostav]

the problem is pipe.read() which is a wrapper on a blocking Win32 api

[groostav]

what im looking to do here is add that adaptive layer to convert my blocking API into a coroutine based one. Thats why I wanted the cachedThreadPool

[kirillrakhman]

I thnik what you can do is create a channel, then start one coroutine that calls the blocking api and pushes the results into the channel. then start a second coroutine that reads from the channel and never blocks

[groostav]

as long as I make sure the first is on the `cachedThreadPool.asDispatcher()`'s context then I'm not blocking any resources. cool.

[kirillrakhman]

do you have multiple jobs that call the blocking api?

[kirillrakhman]

i.e., is onStart called multiple times?

[groostav]

not that specifically, but yes it needs to tolerate parallelism

[groostav]

one piece of that parellism is a heartbeat which happens even 5 seconds regardless of what else is going on. Another caller can independently run a transaction

[kirillrakhman]

ok

[groostav]

and thats what the readMessage() synchronized block is, I want to express a map with a kind of run-off. Its not synchronizing for any good reason except I need to sorta check one collection and maybe modify another based on contents

[kirillrakhman]

it's hard to say anymore without knowledge of your domain. in any case, make sure you've read the coroutines document on github and try to understand the philosophy. blocking and synchronizing can be indicators that there might be a more coroutin-y way to do the same thing

[groostav]

yeah thats precisely what im thinking

[groostav]

its funny I spent some time in go and I remember wishing I had that stuff in java, now that I do I realize im too baked in to properly use it 😕

[groostav]

I think that if i use a singleThreadedExecutor, that would effectively serialize my accesses, then readMessage() can become suspend fun readMessage(): MessageDTO = run(singleThreadedDispatcher)

[groostav]

hmm, more reading! thanks for the help