Hey guys, kotlin co routine multiplatform mentione...

# coroutines

[Cyrille QUÉMIN]

Hey guys, kotlin co routine multiplatform mentioned that it is single thread (js style) on native platform. Is it exactly like JS with a delegation principal to a background thread? Or does everything solely run on the main thread ??? If so. Is there a way to "hook" it up to iOS dispatch system in order to have at least one more thread to be able to do computation in the background and updating progress on the main thread for example?

[basher]

Using GCD is difficult because it doesn't guarantee execution on one thread, just in the context of a single queue

[basher]

And that doesn't work well with the native concurrency model

[basher]

We made http://github.com/autodesk/coroutineworker to help with this problem (until there's a general solution)

[Cyrille QUÉMIN]

Thanks @basher I’ll have a look

[Kevin Gorham]

@basher this looks really cool but the api is so different. It seems like maybe with a few api changes it could be used interchangeably with existing code rather than having to cater specifically to a separate api surface.
For instance kotlinx-coroutines-test has Dispatchers.setMain if this library did something similar then it might be easier to integrate with.

[basher]

@Kevin Gorham can you provide more detail? I'd like to know more about the code you'd like to be able to use interchangeably with CoroutineWorker

[Kevin Gorham]

Sure thing! I'm going to write a multiplatform library soon so anything related to getting coroutines working on iOS shows up on my radar. I have an existing library in Android that makes heavy use of coroutines and I have to make it work on iOS and Web. If I used coroutineworker, it looks like I'd have to change the way the existing Android lib works. Ideally, I could minimize or eliminate that as I'd imagine others would desire, as well.

[basher]

Oh I see what you mean. The main issue there is that you can't make a dispatcher multi-threaded on native right now. Once that's possible, this library will be obsolete (i.e. will be part of kotlinx.coroutines)

[Kevin Gorham]

Hmm. Sounds like coroutines aren't useable on iOS, then. The library I'm writing needs to feel idiomatic to native devs. I guess this will be harder than I thought 😞

[basher]

CoroutineWorker exists to fill in the gap temporarily. When full support comes, you can replace CoroutineWorker.execute with launch inside of a CoroutineScope, for example. The API was designed to more closely match the Worker API on native, since that's closer to what's actually happening behind the scenes on native. The general idea is that the coroutine abstraction is great and therefore worth the temporary pain of using CoroutineWorker to help things along and allow writing coroutine-based async code. Then when full support on native comes, you can remove CoroutineWorker, do a small amount of cleanup, and be left with "idiomatic" coroutine code

[Kevin Gorham]

That sounds useful! Thanks for creating this! But launch is a coroutine builder. It seems having a mechanism for creating a scope (more specifically, an implementation of CoroutineDispatcher) might be more flexible. I'm away from home today but I'll take a look at this library over the weekend and if I have more specific feedback, I'll file an issue on the repo.

[basher]

Right I tried (maybe badly) to hint at that: " with launch inside of a CoroutineScope,".

[basher]

more specifically, an implementation of CoroutineDispatcher

This is the part that's not possible today in the current native memory concurrency model. I explained this in detail here (also mentioned GCD in that thread some where too): https://kotlinlang.slack.com/archives/C3PQML5NU/p1560272716107300?thread_ts=1560269181.105800&cid=C3PQML5NU