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

groostav

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

kirillrakhman

04/26/2017, 8:13 AM
what is it exactly I should look for?
g

groostav

04/26/2017, 8:14 AM
specifically im only using CompletableFutures and olde-school java in the dispatching component
Is that as good as it gets?
k

kirillrakhman

04/26/2017, 8:16 AM
g

groostav

04/26/2017, 8:16 AM
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()
k

kirillrakhman

04/26/2017, 8:16 AM
there is a coroutine builder
future
for creating a coroutine that returns a
CompletableFuture
g

groostav

04/26/2017, 8:18 AM
I think im OK to expose a
suspend fun read(): Message
instead of a
fun read(): CompletableFuture<Message>
there
although I do like the idea of object-boundaries being java compatable where its not too intrusive
k

kirillrakhman

04/26/2017, 8:18 AM
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
g

groostav

04/26/2017, 8:19 AM
the problem is
pipe.read()
which is a wrapper on a blocking Win32 api
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
k

kirillrakhman

04/26/2017, 8:21 AM
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
g

groostav

04/26/2017, 8:22 AM
as long as I make sure the first is on the `cachedThreadPool.asDispatcher()`'s context then I'm not blocking any resources. cool.
k

kirillrakhman

04/26/2017, 8:23 AM
do you have multiple jobs that call the blocking api?
i.e., is
onStart
called multiple times?
g

groostav

04/26/2017, 8:24 AM
not that specifically, but yes it needs to tolerate parallelism
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
k

kirillrakhman

04/26/2017, 8:26 AM
ok
g

groostav

04/26/2017, 8:28 AM
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
k

kirillrakhman

04/26/2017, 8:31 AM
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
g

groostav

04/26/2017, 8:33 AM
yeah thats precisely what im thinking
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 😕
I think that if i use a singleThreadedExecutor, that would effectively serialize my accesses, then
readMessage()
can become
suspend fun readMessage(): MessageDTO = run(singleThreadedDispatcher)
hmm, more reading! thanks for the help
4 Views